Greeting,

while fiddling with some old ideas I unintentionally managed to improve 
some aspects of my img2mesh Python image to heightfield 3D mesh converter.

You can view the results at the top of img2mesh page, updates section:

https://dnyarri.github.io/img2mesh.html

and download either Python originals or compiled Win10 exe.

In view of recent discussion "I would like to ask the community: do
we really need it?"

I mean new version uses geometry switch based on source local contrast, 
corresponding threshold control is added to program GUI but, obviously, 
it doesn't give real-time preview of final rendering. In theory, I may 
add something like ruby mask preview (like one in Photoshop) for local 
contrast to GUI, but, considering my extremely poor programming skills 
and bad memory, it would be quite time consuming. Surely, I was able to 
make a preview for filtering (you may see it at the bottom of my POV‑Ray 
Thread: Linen and Stitch at

https://dnyarri.github.io/povthread.html#averager

so I can do this, but it wasn't easy.

So, the question is: does anybody really need this img2mesh and stuff?

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greeting,
> ...
> In view of recent discussion "I would like to ask the community: do
> we really need it?"
> ...
> So, the question is: does anybody really need this img2mesh and stuff?

interesting question, though not, perhaps, the correct one </grin>.  will think
about it more but "gut feeling" says yes.  not just because, in a real sense, it
is new/different, but there's also the "aspect" that as creator of XYZ you have
no control, and can have no real idea, what uses others have/will find for XYZ.


regards, jr.

Post a reply to this message

On 22/09/2025 12:39, Ilya Razmanov wrote:
> 
> So, the question is: does anybody really need this img2mesh and stuff?
> 
Congratulations, this is excellent work !
I guess this method will be demanded not only by POV-Ray community, may
be I will manage myself to rewrite it on Javascript to extent Three.js
library (asking your permission before :)).

-- 
YB

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greeting,

Interesting what you do with the sharp transitions.

Other method that could work in various cases:

1. First calculate the face normal, either by cross product of three edges or
Newell's method

Newell:
  for i in 0..<vertices.len:
    let curr = vertices[i]
    let next = vertices[(i + 1) mod vertices.len]
    normal.x += (curr.y - next.y) * (curr.z + next.z)
    normal.y += (curr.z - next.z) * (curr.x + next.x)
    normal.z += (curr.x - next.x) * (curr.y + next.y)
  return normalize(normal)

2. Now calulate the vertex normals, there several weighting types can be used,
based on properties of the adjacent polygons.
   Weighted by area, weighted by angle or just average the face normals as they
are.


Regarding usefulness, always. Users do crazy things :) It may also be useful if
you provide an export as arrays, so one can (ab)use the data in SDL.

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> 1. First calculate the face normal, either by cross product of three edges or
> Newell's method
>
> Newell:
>   for i in 0..<vertices.len:
>     let curr = vertices[i]
>     let next = vertices[(i + 1) mod vertices.len]
>     normal.x += (curr.y - next.y) * (curr.z + next.z)
>     normal.y += (curr.z - next.z) * (curr.x + next.x)
>     normal.z += (curr.x - next.x) * (curr.y + next.y)
>   return normalize(normal)
>
> 2. Now calulate the vertex normals, there several weighting types can be used,
> based on properties of the adjacent polygons.
>    Weighted by area, weighted by angle or just average the face normals as they
> are.

You're making me want to revisit one of my other small projects:

https://news.povray.org/web.655dee4084c692a31f9dae3025979125%40news.povray.org

Too much to do, too little time.

- BW

Post a reply to this message

On 23.09.2025 14:53, ingo wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> Greeting,
> 
> Interesting what you do with the sharp transitions.

Oh, it's all pretty simple (remember that I started it for my own use, 
and not a science project).

I was disappointed with the way POV-Ray treats bitmapped heighfield, and 
decided to try some heighfiled to mesh conversion on my own. Initial 
idea was simple: lets assume we have 2x2 pixel area of source image, 
numbering pixels according to Soviet Army "snail" rule:

1 2
4 3

those values (brightness) we name v1 - v4.

Simplest way to make triangles would be two triangles, 1-2-4 and 2-3-4, 
forming a square, folded along 2-4 diagonal. It works, but not too cool, 
so instead of 2 triangle fold I tried 4 triangle pyramid, involving 
interpolated point 0, having v0 = (v1 + v2 + v3 +v4) / 4. So four 
triangles looked like 1-2-0, 2-3-0, 3-4-0 and 4-1-0. This looked 
definitely better than POV-Ray heighfield; I also tried to compare it 
with patches and found to be similar). However I don't like artifacts 
like peaks it produces for cone gradients. But spontaneously I though 
that fold structure above is a case of pyramid structure with v0 = (v2 + 
v4) /2, so combining two geometries is only a matter of setting v0 to 
average of either two or four pixels. So I did this; decision is based 
on simple criterion:


# ↓ Switch between geometry №1 and №3.
#   Threshold set ad hoc and is subject to change
if abs(v1 - v3) > threshold or abs(v2 - v4) > threshold:
     # ↓ Geometry №1, better sharp diagonals handling
     if abs(v1 - v3) > abs(v2 - v4):
         v0 = (v2 + v4) / 2  # Fold along 2 - 4 diagonal
     else:
         v0 = (v1 + v3) / 2  # Fold along 1 - 3 diagonal
else:
     # ↓ Geometry №3, better for smooth areas
     v0 = (v1 + v2 + v3 + v4) / 4

Note that it includes two folding directions, 2-4 and 1-3, for / and \ 
diagonals.

So, now I have only one problem: choosing threshold. Surely I used 
common sense (I have vast supplies of common sense, "hot' lozhkoy zhuy") 
and added some experiments to it before setting defaults, but it's still 
a matter to discuss.

 > 1. First calculate the face normal

As we are talking of source image areas like 2x2 pixels, I see no sense 
in calculating normal and other wise and complicated stuff. I think I 
can make decisions regarding local source contrast based on simple 
arithmetics like difference and stuff.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 23.09.2025 13:46, yesbird wrote:

> I guess this method will be demanded not only by POV-Ray community, may
> be I will manage myself to rewrite it on Javascript to extent Three.js
> library (asking your permission before :)
You are allowed to use it as long as you keep hailing the Toad all the 
time. Oh, and bring me all your money you silly humans.

Seriously, I don't see anything special regarding my algorithm, just 
some common sense, so surely use it at will if you find it useful.

In fact, there is a room for improvements: I use the fact that fold 
geometry is just a particular case of pyramid one, and I use it with 
"sharp" threshold-based "if" condition. Surely I may try some "smooth" 
solution, with folds gradually turning into pyramids, for example, 
linearly based on local contrast. The problem is, all this comes to "I 
like the way it looks" criterion in the end, and I still don't have 
precise mathematical definition for "look", not to mention "like".

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:

> Oh, it's all pretty simple (remember that I started it for my own use,
> and not a science project).

To me, this seems similar to a convolution kernel.
I wonder if you could draw inspiration from that field and achieve some other
effects.  All of your other experiments have yielded really nice results, so I
can only imagine that you would develop some pretty spectacular stuff.

- bw

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Greeting,
>
> while fiddling with some old ideas I unintentionally managed to improve
> some aspects of my img2mesh Python image to heightfield 3D mesh converter.
>
> You can view the results at the top of img2mesh page, updates section:
>
> https://dnyarri.github.io/img2mesh.html
>
> and download either Python originals or compiled Win10 exe.
>
> In view of recent discussion "I would like to ask the community: do
> we really need it?"
>
> I mean new version uses geometry switch based on source local contrast,
> corresponding threshold control is added to program GUI but, obviously,
> it doesn't give real-time preview of final rendering. In theory, I may
> add something like ruby mask preview (like one in Photoshop) for local
> contrast to GUI, but, considering my extremely poor programming skills
> and bad memory, it would be quite time consuming. Surely, I was able to
> make a preview for filtering (you may see it at the bottom of my POV‑Ray
> Thread: Linen and Stitch at
>
> https://dnyarri.github.io/povthread.html#averager
>
> so I can do this, but it wasn't easy.
>
> So, the question is: does anybody really need this img2mesh and stuff?
>
> --
> Ilyich the Toad
> https://dnyarri.github.io/

Latest proposition for sharp transtion is very cool and even more "opinionated"
features like that are what give it most purpose !
I did not think of it that way before but if turned into a python library
without any other dependencies than those shipped in Blender (getting it more
easily "substitutable" to tkinter) , this would definitely be a good candidate
to integrate as an option for low res enhancement within the current POV@Ble
(blender's POV addon) heightfield primitive!

Post a reply to this message

On 30.09.2025 13:24, Mr wrote:

> features like that are what give it most purpose !
> I did not think of it that way before but if turned into a python library
> without any other dependencies than those shipped in Blender (getting it more
> easily "substitutable" to tkinter) , this would definitely be a good candidate
> to integrate as an option for low res enhancement within the current POV@Ble
> (blender's POV addon) heightfield primitive!

This would require me learning Blender addons API. Currently my export 
modules for img2mesh are a module already, but they are written to 
receive source image data in the form I like, namely nested list. I find 
this form both logical and suitable (my POV-Ray Mesh includes image 
filtering module, and if you take a look at it, you'll see that this 
image structure allowed me to write simple generalized filter for 
arbitrary number of channels - it simply processes lists/vectors via map 
regardless of their length). So my programs are rather modular, but in 
the way I like. Others may have different ideas.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message