May I ask an important question?
When I using mesh_camera, (for texture baking), its coverage is not sufficient
at the edge(seams). Just like the document said:

-----------
If used for texture baking, the generated image may have visible seams when
applied back to the mesh, this can be mitigated. Also, depending on the way the
original UV map was set up, using AA may produce incorrect pixels on the outside
edge of the generated maps.

-----------

Has this problem been solved?


Here is the output image from UberPOV version 1.37.1.1-alpha.8756754

Post a reply to this message

Attachments:
Download 'uv_test_pov_scene ver6.png' (128 KB)

Preview of image 'uv_test_pov_scene ver6.png'

Then applied the image to the mesh(for texture):

It has a visible seam.

Post a reply to this message

Attachments:
Download 'finish.png' (846 KB)

Preview of image 'finish.png'

"And" <49341109@ntnu.edu.tw> wrote:
> Then applied the image to the mesh(for texture):
>
> It has a visible seam.

No matter I use AA or not, this seam exist.

If it cannot be eliminated with POV-Ray, I will write a small program for my
self to extend the color(maybe 2~ 3 pixel). But It is more like what POV-Ray can
finish.

Post a reply to this message

Attachments:
Download 'thought.png' (175 KB)

Preview of image 'thought.png'

On 11/12/22 04:04, And wrote:
> May I ask an important question?
> When I using mesh_camera, (for texture baking), its coverage is not sufficient
> at the edge(seams). Just like the document said:
> 
> -----------
> If used for texture baking, the generated image may have visible seams when
> applied back to the mesh, this can be mitigated. Also, depending on the way the
> original UV map was set up, using AA may produce incorrect pixels on the outside
> edge of the generated maps.
> 
> -----------
> 
> Has this problem been solved?

I'm not aware of a general solution. I don't generate or use uv maps 
much, but some ideas.

- If you are not using interpolation when reading the image map, suspect 
using it might lesson the seam artifact in your case. Interpolation may 
also introduce seams in other cases I think.

- For simpler shapes using the matching camera type - ie spherical 
camera - to create the map images and then the same image_map mapping 
will be cleaner than mesh based texture baking and uv mapping.

- 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.

- IIRC, there are some suggested ways to bake map images via meshes 
while doing some AA via different meshes which might help. I've never 
played with the technique outlined. I suspect POV-Ray's inbuilt camera 
ray AA won't be of much help.

- Scaling your uv map image up say 2x/3x in an external program will 
likely mitigate the seams.

- Have you tried rendering at different output resolutions to see how 
any seams might change? (Rendering large and shrinking a help?)

---
I have for a long time wondered how seams in the map image are handled 
in the non POV-Ray cgi game. There images are typically cookie cutter 
sheets for different parts of the uv mapping onto the overall mesh. Maps 
I've played with 'sometimes' have visible seams too which in my 
experience often do create minor artifacts...

When we read an image map we can use (pixel) interpolation - but we 
perhaps should not where image maps used for uv mapping (or for any 
non-continuous mapping such as images for cubic warps). The reason is 
the seams cut off sharply in many uv image maps and any interpolation 
will be looking at adjacent (or wrapped) pixels and not pixel adjacency 
as the image is used in uv mapping on the mesh. This, I think, forces us 
to higher resolution maps than might otherwise be required for smooth 
rendered results.

It is possible with cubic warp mapped images, for example, to create the 
images in a way which looks for and includes the correct adjacent pixels 
at the seams so that smaller, interpolated images can be used while uv 
mapping. I think I posted about some of my experiments - using user 
defined cameras to create such 'interpolate-able' images. Unsure how to 
do this in general. Perhaps there are too some post initial image mesh 
walking AA / smoothing techniques possible, but I'm not aware of 
anything like a canned program though.

Anyhow... Interested.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> > -----------
> >
> > Has this problem been solved?
>
> I'm not aware of a general solution. I don't generate or use uv maps
> much, but some ideas.
>
> - If you are not using interpolation when reading the image map, suspect
> using it might lesson the seam artifact in your case. Interpolation may
> also introduce seams in other cases I think.
>
> - For simpler shapes using the matching camera type - ie spherical
> camera - to create the map images and then the same image_map mapping
> will be cleaner than mesh based texture baking and uv mapping.
>


> - IIRC, there are some suggested ways to bake map images via meshes
> while doing some AA via different meshes which might help. I've never
> played with the technique outlined. I suspect POV-Ray's inbuilt camera
> ray AA won't be of much help.
>
> - Scaling your uv map image up say 2x/3x in an external program will
> likely mitigate the seams.
>


>
> ---
> I have for a long time wondered how seams in the map image are handled
> in the non POV-Ray cgi game. There images are typically cookie cutter
> sheets for different parts of the uv mapping onto the overall mesh. Maps
> I've played with 'sometimes' have visible seams too which in my
> experience often do create minor artifacts...
>
> When we read an image map we can use (pixel) interpolation - but we
> perhaps should not where image maps used for uv mapping (or for any
> non-continuous mapping such as images for cubic warps). The reason is
> the seams cut off sharply in many uv image maps and any interpolation
> will be looking at adjacent (or wrapped) pixels and not pixel adjacency
> as the image is used in uv mapping on the mesh. This, I think, forces us
> to higher resolution maps than might otherwise be required for smooth
> rendered results.
>
> It is possible with cubic warp mapped images, for example, to create the
> images in a way which looks for and includes the correct adjacent pixels
> at the seams so that smaller, interpolated images can be used while uv
> mapping. I think I posted about some of my experiments - using user
> defined cameras to create such 'interpolate-able' images. Unsure how to
> do this in general. Perhaps there are too some post initial image mesh
> walking AA / smoothing techniques possible, but I'm not aware of
> anything like a canned program though.
>
> Anyhow... Interested.
>
> Bill P.


Thanks for your reply.

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.

Post a reply to this message

Attachments:
Download 'finish using 2048x2048 texture.png' (844 KB)

Preview of image 'finish using 2048x2048 texture.png'

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 
right)

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

William F Pokorny <ano### [at] anonymousorg> wrote:
> 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').
> >
> > -------------------------------------------------------------
> >
> >
> > 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.
>

I render a 4800x4800 map with the same setting this time.(attachment image)

---------------------------------------------------------------

> 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
> right)
>

I always use this setting:

Antialias=On
Antialias_Threshold=0.05
Sampling_Method=1
Antialias_Depth=4
Quality=11
+SP32
+EP32


---------------------------------------------------------------

> 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.


I never tried using jitter with these series. And I use it seldom...





------------------------------------------
- For simpler shapes using the matching camera type - ie spherical
camera - to create the map images and then the same image_map mapping
will be cleaner than mesh based texture baking and uv mapping.
------------------------------------------

I'm not aware this. I just want to produce mesh based texture baking. (for
general modeling shape produced with Blender)

Post a reply to this message

Attachments:
Download 'finish using 4800x4800 texture.png' (853 KB)

Preview of image 'finish using 4800x4800 texture.png'

I tried jitter just now. But I cannot distinguish the result.

(add this on povray.ini)
Jitter = true



1024x1024 output:(same size as the first blender image of this thread) -> uv-map

Post a reply to this message

Attachments:
Download 'finish using 1024x1024 with jitter texture.png' (828 KB)

Preview of image 'finish using 1024x1024 with jitter texture.png'

On 11/14/22 11:11, And wrote:
> I always use this setting:
> 
> Antialias=On
> Antialias_Threshold=0.05
> Sampling_Method=1
> Antialias_Depth=4

Saw the other post. For AA, it'd be interesting to see if

Antialias_Threshold=0.015
Sampling_Method=2

gives a better / different result.


---
Aside: There is too method 3, but unsure where uberPOV is with respect 
to that code. UberPOV's implementation of method 3 came first and did 
not match exactly what made it into v3.8/v4.0 - IIRC. Further, I believe 
it still the case, all the official implementations have the potential 
run-away / run to max samples issue when one or more color channels goes 
negative(a,b) due floating point rounding errors.

(a) - The runaway situation consumes a lot of time, but also is where I 
suspect method 3 returns the best end result.

(b) - The fix, posted about somewhere in the newsgroups, was to add code 
which clamps all negative color channel values to zero so that sqrt() 
functions used by method 3 are happy.

Bill P.

Post a reply to this message

Wow, you use Antialias_Threshold=0.015
such a small value.
At beginning, I think this value should take only one place next to decimal
point. 0.1 is its minimum, or zero, but zero will calculate every pixel, so not
very fine to me...
After one day, I found it can assign a more meticulous value, so I use 0.05.
I think it is good enough.
I don't know the habit of other people.
(I means when I render several types of pictures, not particularly to texture
map)


Sampling_Method=2
Oh, ... I seldom use it after my learning and investigate the anti-alias.
Recursive method take many time to render is my opinion. Maybe I don't need such
meticulous sampling yet.

Sampling_Method=3
?? I don't know it.

Post a reply to this message