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