Hi, guys !

While working on my Matlab toolbox project
(https://www.mathworks.com/matlabcentral/fileexchange/123520-pov-lab-matlab-interface-to-pov-ray)
I found strange artifact that looks like mesh collision when rendering (scene
and example attached).

Could anyone suggest to me how to avoid it or at least make it less perceptible
?

Rendering params are following:
[1024x768, AA 0.3]
Width=1024
Height=768
Antialias=On
Antialias_Threshold=0.3

Thanks in advance.

Post a reply to this message

Attachments:
Download 'out.zip' (289 KB)

PS: Version: POV-Ray for Windows 3.7.0

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
> Hi, guys !
>
> While working on my Matlab toolbox project
>
(https://www.mathworks.com/matlabcentral/fileexchange/123520-pov-lab-matlab-interface-to-pov-ray)
> I found strange artifact that looks like mesh collision when rendering (scene
> and example attached).
>
> Could anyone suggest to me how to avoid it or at least make it less perceptible
> ?


So, there are a multitude of problems with how the scene is constructed.

First, you are using a clear texture (glass) for half of the triangles, and so I
think what you are seeing is part of the perspective of looking _through_ those
triangles, and getting shadows.

Rotate your camera or the mesh to look right at that section and see if it still
looks ok.

You could also just use simple pigments and see if the problem "goes away".

You're using regular triangles instead of smooth_triangles, and so you get a
noticeable "crease" diagonally across your squares.

In your mesh definition you have a large collection of triangles.  You could
probably do that more efficiently by defining a list of vertices and using a
small macro to make triangles out of them, yielding a smaller scene file.


These are your scene files, so proceed as you wish, but I have tended to get
away from using too many include files if at all possible.   If you only have a
few textures or functions that you need for your scene, it might be better for
portability, historical archiving, and debugging if you copied the bits of code
from the include files into your scene so that they are permanent and
inseperable.  You could add a comment "copied from 'somefile.inc'" so that
people could know where you got the code from, etc.

Along those lines, mesh2 would be better to edit the mesh, since you'd be
defining triangles with references to vertices, not the native coordinates for
every shared vertex.  I'd also strongly consider declaring texture variables
that are used in the mesh, that way you could edit a single line at the
beginning of the scene file, and not have to edit or search/find/replace every
single instance.

You'll likely want to start a versioning system now, before things get too far
along.   Add a comment block that states what software generates the SDL scene
file, what version, date, author, POV-Ray version being used, etc.
Binary copying a png or jpg image and the scene text file into a PDF
(post-render) permanently ties them together so that the code that generated the
image never gets lost.



Overall, small easy things to fix, and you're looking good right out of the
gate!   I hope to see more fun shapes and surfaces, and maybe even new visitors.
 :)

Post a reply to this message

"yesbird" <nomail@nomail> wrote:
> Hi, guys !
>
> While working on my Matlab toolbox project
>
(https://www.mathworks.com/matlabcentral/fileexchange/123520-pov-lab-matlab-interface-to-pov-ray)
> I found strange artifact that looks like mesh collision when rendering (scene
> and example attached).
>
> Could anyone suggest to me how to avoid it or at least make it less perceptible
> ?

Hi yesbird

I guess that if you add this to your scene:

sphere {
    <+4.3, -2.2,  0.0>, 1.2
    pigment { color red 0.5 }
}

- then you'll see what's going on.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

Thank you very much for rapid and detailed reply !

I will implement all suggested approached and inform you about results. I am not
sure about shadows, because all lights are 'shadowless', but all other staff
looks very promising.

You absolutely right about about importans of making right decisions ASAP, at
the start of the project - this is the reason why I am asking about professional
support.

As to scene structure and editing, I am generating it by Matlab script, so
manual editing is not assuming, but in any case I see that moving to mesh2 is a
must, at least to save time for parsing.

And for sure, I am using versioning system, it's here:
https://github.com/syanenko/POV-Lab

Thanks again for you support.
-- Serge (Yesbird)

Post a reply to this message

> Hi yesbird
>
> I guess that if you add this to your scene:
>
> sphere {
>     <+4.3, -2.2,  0.0>, 1.2
>     pigment { color red 0.5 }
> }
>
> - then you'll see what's going on.
>
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k

Hi, Tor.
Thanks for suggestion.
A miracle happened - problem has gone, but I can't figure out why.

Post a reply to this message

Result in attachment

Post a reply to this message

Attachments:
Download 'mesh.png' (232 KB)

Preview of image 'mesh.png'

"yesbird" <nomail@nomail> wrote:
> > Hi yesbird
> >
> > I guess that if you add this to your scene:
> >
> > sphere {
> >     <+4.3, -2.2,  0.0>, 1.2
> >     pigment { color red 0.5 }
> > }
> >
> > - then you'll see what's going on.
> >
> > --
> > Tor Olav
> > http://subcube.com
> > https://github.com/t-o-k
>
> Hi, Tor.
> Thanks for suggestion.
> A miracle happened - problem has gone, but I can't figure out why.

This just gives your checkered plane textured surface something else
to reflect than itself.

What you saw was just reflections of several bright white squares.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

> This just gives your checkered plane textured surface something else
> to reflect than itself.
>
> What you saw was just reflections of several bright white squares.
>
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k

So simple ! Thanks  lot !

Post a reply to this message

"yesbird" <nomail@nomail> wrote:


> As to scene structure and editing, I am generating it by Matlab script, so
> manual editing is not assuming, but in any case I see that moving to mesh2 is a
> must, at least to save time for parsing.

To be honest, you're going to parse and render simple scenes like this in
seconds, so it's not much of an issue.  I'm just not sure how large things might
get in the future, or how many such objects would be rendered or parsed in a
scene by any given user.

So as far as all this goes:

Create camera object and put it in separate include file to save rendering time
in future

Create lights objects and put them in separate include file to save rendering
time in future

Create environment objects and put them in separate include file to save
rendering time in future

Id say you're shaving off milliseconds at most.  Keep it in the file so it's a
standalone render.

As far as manual editing, you might have someone making a diagram, or changing
the texture of a specific grid square to highlight that portion of the equation,
or ....   so the output of your scripts might only be the beginning of someone
else's workflow.

And as far as that goes, people might very well use your utilities for making
illustrations for documents or slides for presentations - and so you might start
thinking ahead with regard to offering a side-by-side layout showing what
equation is being graphed, numbering or graphing macros/algorithms written by
myself, Tor, and the excellent Tabulated system developed by jr.
Just some things to mull over when you're trying to get to sleep.  ;)  :D

> And for sure, I am using versioning system, it's here:
> https://github.com/syanenko/POV-Lab

I meant as a comment block in the scene file itself.  It's always nice to be
able to tell where a file came from (and when) and sometimes by who.   Including
the version of MatLab and POV-Ray at the time of creation helps solve future
archaeological mysteries.
"Who the heck wrote THIS code???"    "Ohhhhh... 'automatically generated by...'
  plus it was made 15 years ago when computers were slow and POV-Ray was still
in version 3.8, so they didn't have features x, y, and z"

As you can see, you got tricked into seeing and misinterpreting a problem with
reflections.   I'd keep things simple for visibility purposes, and also
reflections are costly in terms of render time.
As you progress in developing your scripting, you can experiment with different
colors, textures, normals, and finishes.  This will make it easier for a viewer
to correctly interpret the mathematical surface being represented using the
available visual cues.  So good shadows, a small surface normal, and some
specular highlighting can go a long way.

http://warp.povusers.org/povtips/

Also, if you're going to provide text, I'd choose something that represents
mathematical symbols well, and does a good job with regard to readability and
differentiating things like 1 and l, O and 0, etc.

You might consider Atkinson Hyperlegible font
https://brailleinstitute.org/freefont

IIRC I've also had good success with Arial Unicode MS and Lucida Sans Unicode.

Others have suggested SF Mono, JetBrains Mono, IBM Plex Mono, Source Code Pro,
Fira Code, Fira Mono, and Recursive Mono.

There are also other graphing / mathematical visualization packages the use
POV-Ray that you might look to for inspiration.

Post a reply to this message