Is there a way to get Povray to automatically calculate smoothed normals
for a mesh2?

I'm generating huge meshes from an external procedural terrain
generator. The generator assumes that the renderer doesn't need explicit
normals, so not only does it not write them but it lacks the
functionality internally to go from a vertex to the facets containing
the vertex. So adding support for calculating smoothed normals is going
to be non-trivial.

Most other renderers I've looked at have an option to do this
automatically. Does Povray?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

David Given <dg### [at] cowlarkcom> wrote:
> Is there a way to get Povray to automatically calculate smoothed normals
> for a mesh2?

Currently, no.

(Such a feature might be added in the future, either as a direct feature,
or by enhancing the language so that it could be easily written as a
script.)

-- 
                                                          - Warp

Post a reply to this message

Le 06/12/2013 15:09, Warp a écrit :
> David Given <dg### [at] cowlarkcom> wrote:
>> Is there a way to get Povray to automatically calculate smoothed normals
>> for a mesh2?
> 
> Currently, no.

And the real tricky question is: how do you weight the various normals
at a vertex ?
So far I came with at least 4 different ways.

And for information: mesh2 is only a syntax, mesh & mesh2 are the same
internal object inside povray.
(yet, mesh2 is parsed much faster when it becomes long)

> 
> (Such a feature might be added in the future, either as a direct feature,

Done as a direct feature: smooth{...}
Illustration at:
http://wiki.povray.org/content/User:Le_Forgeron#smooth

Source code at:
https://bitbucket.org/LeForgeron/hgpovray

> or by enhancing the language so that it could be easily written as a
> script.)
> 


-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

Am 06.12.2013 14:26, schrieb David Given:
> Is there a way to get Povray to automatically calculate smoothed normals
> for a mesh2?
>
> I'm generating huge meshes from an external procedural terrain
> generator. The generator assumes that the renderer doesn't need explicit
> normals, so not only does it not write them but it lacks the
> functionality internally to go from a vertex to the facets containing
> the vertex. So adding support for calculating smoothed normals is going
> to be non-trivial.

POV-Ray has essentially the same problem: While it does know which 
vertices belong to a given facet, it would need an exhaustive search of 
the facets list to figure out which faces meet at a given vertex.

One thing you might do is first render the non-smoothed mesh in an 
orthographic scene with a gradient pattern applied, giving you a height 
map image; you can then feed that image into a smoothed height field.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> And the real tricky question is: how do you weight the various normals
> at a vertex ?
> So far I came with at least 4 different ways.

Well, the most common way is that, for each vertex, you take the normal
vectors of all the triangles that share that vertex, and calculate their
weighted average, the weight factor being the area of the triangle.
(This works better than just a regular average because it gives a smoother
result with meshes containing triangles of very differing sizes.)

Of course mesh models often contain sharp edges. It's naturally impossible
to know which edges are supposed to be sharp and which smooth because that
information is lost, but the algorithm can make an educated guess by
simply considering the edge between two triangles to be sharp if the
angle between the normals of those triangles is larger than a threshold
(which can be user-specified.)

Vertices at sharp edges/corners naturally require for two or more normals
to be created (one for each set of triangles that's on one side of the
sharp edge.)

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> POV-Ray has essentially the same problem: While it does know which
> vertices belong to a given facet, it would need an exhaustive search of
> the facets list to figure out which faces meet at a given vertex.

Well how did the subdivision patch do it, then? As I recall it was very fast, at
both subdivision and automatically calculating vertex normals. (I really miss
that patch!)

Sam

Post a reply to this message

David Given <dg### [at] cowlarkcom> wrote:
> Is there a way to get Povray to automatically calculate smoothed normals
> for a mesh2?
>
> I'm generating huge meshes from an external procedural terrain
> generator. The generator assumes that the renderer doesn't need explicit
> normals, so not only does it not write them but it lacks the
> functionality internally to go from a vertex to the facets containing
> the vertex. So adding support for calculating smoothed normals is going
> to be non-trivial.
>
> Most other renderers I've looked at have an option to do this
> automatically. Does Povray?
>
If the mesh can be saved as obj and is not to large than PoseRay may be an
option to (re)calculate normals and save the object as pov-source. PoseRay
provides some options to calculate the normals and you have a preview. But IIRC
the grid can not be to large.

Best regards,
Micahel

Post a reply to this message

El 06/12/13 19:37, MichaelJF escribi�:
> David Given <dg### [at] cowlarkcom> wrote:
>> Is there a way to get Povray to automatically calculate smoothed normals
>> for a mesh2?
>>
> If the mesh can be saved as obj and is not to large than PoseRay may be an
> option to (re)calculate normals and save the object as pov-source. PoseRay
> provides some options to calculate the normals and you have a preview. But IIRC
> the grid can not be to large.
>

   IIRC, Poseray will even take a mesh2 in POV-Ray format...

--
jaime

Post a reply to this message

Am 06.12.2013 19:12, schrieb Samuel Benge:
> clipka <ano### [at] anonymousorg> wrote:
>> POV-Ray has essentially the same problem: While it does know which
>> vertices belong to a given facet, it would need an exhaustive search of
>> the facets list to figure out which faces meet at a given vertex.
>
> Well how did the subdivision patch do it, then? As I recall it was very fast, at
> both subdivision and automatically calculating vertex normals. (I really miss
> that patch!)

I don't know that patch in detail, but it might have added extra data 
structures to keep track of the information required.

Post a reply to this message

On 06/12/13 16:44, clipka wrote:
[...]
> One thing you might do is first render the non-smoothed mesh in an
> orthographic scene with a gradient pattern applied, giving you a height
> map image; you can then feed that image into a smoothed height field.

I'm modelling entire planets, which are unfortunately round, so the
heightfield primitive isn't much use to me. I've previously been using
isosurfaces but they're just too horrifically painfully slow,
particularly if I want to avoid render artifacts. Going for a polygon
mesh is a new improved system to try and avoid all that.

One day someone's going to come up with a way of storing efficient,
interpolatable spherical heightmap data without the distortion involved
in forcing it into a 2D matrix...

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

On 06/12/13 22:11, David Given wrote:
[...]
> One day someone's going to come up with a way of storing efficient,
> interpolatable spherical heightmap data without the distortion involved
> in forcing it into a 2D matrix...

The Usenet effect strikes again --- as soon as I post, I stumble across
the answer!

http://en.wikipedia.org/wiki/Quadrilateralized_spherical_cube

However I doubt Povray's going to get a COBE sky cube spherical
heightfield primitive any time soon, so it doesn't actually help me much.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Am 06.12.2013 23:16, schrieb David Given:
> On 06/12/13 22:11, David Given wrote:
> [...]
>> One day someone's going to come up with a way of storing efficient,
>> interpolatable spherical heightmap data without the distortion involved
>> in forcing it into a 2D matrix...
>
> The Usenet effect strikes again --- as soon as I post, I stumble across
> the answer!
>
> http://en.wikipedia.org/wiki/Quadrilateralized_spherical_cube
>
> However I doubt Povray's going to get a COBE sky cube spherical
> heightfield primitive any time soon, so it doesn't actually help me much.

The primary problem with a "spherical height field" is that it probably 
doesn't give much advantage over a mesh, as far as rendering time is 
concerned.

That said, I guess a special syntax for "spherical height field" meshes 
would be nice to have (just like mesh2 is also a special syntax for a 
mesh, or like cylinder is actually a syntax for a special case of the 
"cone" primitive); for the tesselation scheme, and possibly also for 
data input, the COBE sky cube might indeed be a good candidate (though 
I'd prefer to use arbitrary patterns for data input, and make the COBE 
sky cube just one more image mapping pattern).

Post a reply to this message

Le 06/12/2013 23:16, David Given nous fit lire :
> On 06/12/13 22:11, David Given wrote:
> [...]
>> One day someone's going to come up with a way of storing efficient,
>> interpolatable spherical heightmap data without the distortion involved
>> in forcing it into a 2D matrix...
> 
> The Usenet effect strikes again --- as soon as I post, I stumble across
> the answer!
> 
> http://en.wikipedia.org/wiki/Quadrilateralized_spherical_cube
> 
> However I doubt Povray's going to get a COBE sky cube spherical
> heightfield primitive any time soon, so it doesn't actually help me much.
> 
Can work for colours, but I wonder if the bins can be elevated or buried
without breaking everything.

It seems fine for painting the sphere, but modification of the shape,
i'm not sure.

But the idea is nice to generate a mesh of a sphere, yet the last
external link is saying that an icosahedron is better than a cube. (but
less easier to serialise the points)

I like it when the resolution goes down to use 31 bits... with just one
byte per pixel, you need just about 2GBytes and that's only for the a
gif-like planet at a level of 14, which still make the side of a bin
about 600m long for the Earth.
You cannot even have individual house or roads.
To spot/draw a car (as a pixel or two), a level of 22 is needed...
(reach a resolution of 2.4 m)
Either 16GBytes of black & white (fax mod), or 128GB for a gif-like.

It might be interesting for a displaying engine (with clipping of the
view), but seems not adapted to the way povray handles the texture so far.

Post a reply to this message

Am 07.12.2013 00:06, schrieb Le_Forgeron:

> Can work for colours, but I wonder if the bins can be elevated or buried
> without breaking everything.

Shouldn't be any problem I guess: Just move the vertices along the 
respective radial direction, and there's no way for the mesh to tangle up.

> But the idea is nice to generate a mesh of a sphere, yet the last
> external link is saying that an icosahedron is better than a cube. (but
> less easier to serialise the points)

That is exactly the point: A collection of 20 triangles sounds like an 
ugly mess to handle; 6 squares sounds much more palatable.

> I like it when the resolution goes down to use 31 bits... with just one
> byte per pixel, you need just about 2GBytes and that's only for the a
> gif-like planet at a level of 14, which still make the side of a bin
> about 600m long for the Earth.
> You cannot even have individual house or roads.
> To spot/draw a car (as a pixel or two), a level of 22 is needed...
> (reach a resolution of 2.4 m)
> Either 16GBytes of black & white (fax mod), or 128GB for a gif-like.
>
> It might be interesting for a displaying engine (with clipping of the
> view), but seems not adapted to the way povray handles the texture so far.

If you're trying to model an entire planet at that resolution, you're 
doing something wrong anyway.

One solution could be to define a sub-section to actually load into memory.

Post a reply to this message

On 12/6/2013 4:24 PM, clipka wrote:
>> It might be interesting for a displaying engine (with clipping of the
>> view), but seems not adapted to the way povray handles the texture so
>> far.
>
> If you're trying to model an entire planet at that resolution, you're
> doing something wrong anyway.
>

Or, use the new "fractal" system for it, which is being fiddled with to 
do precisely that sort of thing, but then.. I have no clue how that even 
works. lol But, yeah, the data needed to handle that, in any practical 
way.. well, there is a bloody good reason no one does it, except in 
flight sim games, which take insane amounts of disk space to manage it.

Post a reply to this message

On 6-12-2013 20:39, Jaime Vives Piqueres wrote:
>    IIRC, Poseray will even take a mesh2 in POV-Ray format...
>

Yes indeed, both mesh and mesh2.

Thomas

Post a reply to this message

On 06/12/13 23:06, Le_Forgeron wrote:
[...]
> I like it when the resolution goes down to use 31 bits... with just one
> byte per pixel, you need just about 2GBytes and that's only for the a
> gif-like planet at a level of 14, which still make the side of a bin
> about 600m long for the Earth.

Well, I'm currently juggling a 6GB dataset of a terrain map of the moon.
(Freely available from NASA.) 2GB isn't unreasonable.

(Feature request: memory mapped uncompressed on-disk lookup tables. I've
given up trying to feed Povray really huge datasets because the time
taken to load them into memory is crippling. If I can just leave them on
disk and use mmap() instead, then not only does only the part of the
data I need get loaded, but it remains loaded between runs. Loads, loads
faster. It's not even slightly hard when using Boost;
boost::memory_mapped_source works everywhere.)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs."
│ --- Flon's Axiom

Post a reply to this message

Le 07/12/2013 19:06, David Given nous fit lire :
> On 06/12/13 23:06, Le_Forgeron wrote:
> [...]
>> I like it when the resolution goes down to use 31 bits... with just one
>> byte per pixel, you need just about 2GBytes and that's only for the a
>> gif-like planet at a level of 14, which still make the side of a bin
>> about 600m long for the Earth.
> 
> Well, I'm currently juggling a 6GB dataset of a terrain map of the moon.
> (Freely available from NASA.) 2GB isn't unreasonable.
> 
> (Feature request: memory mapped uncompressed on-disk lookup tables. I've
> given up trying to feed Povray really huge datasets because the time
> taken to load them into memory is crippling. If I can just leave them on
> disk and use mmap() instead, then not only does only the part of the
> data I need get loaded, but it remains loaded between runs. Loads, loads
> faster. It's not even slightly hard when using Boost;
> boost::memory_mapped_source works everywhere.)
> 
It would be fine for a pigment (evaluation of some points only, when
intersection spot them), but not with a set of triangles which must all
be tested for intersection against all rays.

mmap is not portable (different code for Windows).

Sanity checks:
1. what is the resolution of the final render ?
2. would every data be individually visible (at least have such potential) ?

For instance, a 1920x1080 picture only have 2 Mega pixels. A decimated
data set would be enough.

Post a reply to this message

On 07/12/13 18:18, Le_Forgeron wrote:
[...]
> It would be fine for a pigment (evaluation of some points only, when
> intersection spot them), but not with a set of triangles which must all
> be tested for intersection against all rays.

I'm mainly thinking of pigments --- I have (well, used to have) several
user functions which used pigments as big lookup tables. But it would
also be useful for huge meshes. Even if you have to touch every element,
having a big array of floats or doubles in a memory mapped file is still
going to be better than parsing them out of a text file.

> mmap is not portable (different code for Windows).

boost::memory_mapped_source hides all the platform details. It makes
mapping a file literally two lines of code.

[...]
> 2. would every data be individually visible (at least have such potential) ?

Depends where I put the camera.

Since I'm rendering a planet, then obviously a maximum of half the
dataset will be visible at any one time. The further down the camera is,
then the smaller the subset of the data. But again, one of the
advantages of using a memory mapped file is that I don't have to worry
about this. Only the data that actually gets accessed is loaded into
memory (and then persists to subsequent runs).

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Am 07.12.2013 19:18, schrieb Le_Forgeron:

>> (Feature request: memory mapped uncompressed on-disk lookup tables. I've
>> given up trying to feed Povray really huge datasets because the time
>> taken to load them into memory is crippling. If I can just leave them on
>> disk and use mmap() instead, then not only does only the part of the
>> data I need get loaded, but it remains loaded between runs. Loads, loads
>> faster. It's not even slightly hard when using Boost;
>> boost::memory_mapped_source works everywhere.)
>>
> It would be fine for a pigment (evaluation of some points only, when
> intersection spot them), but not with a set of triangles which must all
> be tested for intersection against all rays.

Mesh has its own internal bounding mechanism, so no need to look up each 
and every triangle.

Post a reply to this message

Le 07/12/2013 20:46, clipka nous fit lire :
> Am 07.12.2013 19:18, schrieb Le_Forgeron:
> 
>>> (Feature request: memory mapped uncompressed on-disk lookup tables. I've
>>> given up trying to feed Povray really huge datasets because the time
>>> taken to load them into memory is crippling. If I can just leave them on
>>> disk and use mmap() instead, then not only does only the part of the
>>> data I need get loaded, but it remains loaded between runs. Loads, loads
>>> faster. It's not even slightly hard when using Boost;
>>> boost::memory_mapped_source works everywhere.)
>>>
>> It would be fine for a pigment (evaluation of some points only, when
>> intersection spot them), but not with a set of triangles which must all
>> be tested for intersection against all rays.
> 
> Mesh has its own internal bounding mechanism, so no need to look up each
> and every triangle.
> 
Yet all the data must be parsed for the bounding mechanism to work.

The idea, if I got it correctly, is to have a pigment evaluated
according to the COBE projection and a file (never parsed).

With boost API, it might even be portable enough.
(but I'm afraid of multi-thread slowing down mmap operation: as each
thread ask for a different points in different area. Well not as obvious
as it might seems)

The trick here is that the idea was suggested inside that thread, but it
would have been better in its own thread.

Post a reply to this message