Am 27.10.2016 um 20:51 schrieb Mike Horvath:

> Also, maybe POV-Ray should support point clouds.

You can always read point cloud data at parse time and convert it to a
bunch of spheres (or a set of blob elements if you're low on memory).

If you want something more complicated, then you'd first have to clarify
what that something is; only then will it be possible to even discuss
how that could be achieved, let alone whether it would be reasonable to
hard-code into POV-Ray.

Post a reply to this message

On 10/28/2016 2:54 AM, clipka wrote:
> Am 27.10.2016 um 20:51 schrieb Mike Horvath:
>
>> Also, maybe POV-Ray should support point clouds.
>
> You can always read point cloud data at parse time and convert it to a
> bunch of spheres (or a set of blob elements if you're low on memory).
>
> If you want something more complicated, then you'd first have to clarify
> what that something is; only then will it be possible to even discuss
> how that could be achieved, let alone whether it would be reasonable to
> hard-code into POV-Ray.
>

Isn't df3's created by tda2df3 part of the way there?
tda2df3.exe encodes the location and colour component, of each point.
With a bit of work with "DF3 Viewer Oosawa". The colour channels can be 
separated and used by PovRay.


-- 

Regards
     Stephen

Post a reply to this message

Am 28.10.2016 um 08:47 schrieb Stephen:

>> You can always read point cloud data at parse time and convert it to a
>> bunch of spheres (or a set of blob elements if you're low on memory).
>>
>> If you want something more complicated, then you'd first have to clarify
>> what that something is; only then will it be possible to even discuss
>> how that could be achieved, let alone whether it would be reasonable to
>> hard-code into POV-Ray.
> 
> Isn't df3's created by tda2df3 part of the way there?
> tda2df3.exe encodes the location and colour component, of each point.

Not sure what you're referring to there; presumably some external tool,
but certainly not part of the official POV-Ray package ;)

So this probably doesn't qualify as whatever Mike had in mind when
suggesting that "POV-Ray should support point clouds".

> With a bit of work with "DF3 Viewer Oosawa". The colour channels can be
> separated and used by PovRay.

Same with this one (though in this case I did manage to figure out what
that thing actually is ;))

Post a reply to this message

On 10/28/2016 8:04 AM, clipka wrote:
> Am 28.10.2016 um 08:47 schrieb Stephen:
>
>>> You can always read point cloud data at parse time and convert it to a
>>> bunch of spheres (or a set of blob elements if you're low on memory).
>>>
>>> If you want something more complicated, then you'd first have to clarify
>>> what that something is; only then will it be possible to even discuss
>>> how that could be achieved, let alone whether it would be reasonable to
>>> hard-code into POV-Ray.
>>
>> Isn't df3's created by tda2df3 part of the way there?
>> tda2df3.exe encodes the location and colour component, of each point.
>
> Not sure what you're referring to there; presumably some external tool,
> but certainly not part of the official POV-Ray package ;)
>

Well spotted. But then, you have the source code memorised. ;)

> So this probably doesn't qualify as whatever Mike had in mind when
> suggesting that "POV-Ray should support point clouds".
>

Are you sure we are talking about the same thing?
It seems to me that df3's are point clouds.

>> With a bit of work with "DF3 Viewer Oosawa". The colour channels can be
>> separated and used by PovRay.
>
> Same with this one (though in this case I did manage to figure out what
> that thing actually is ;))
>
Oo! Tell me then, please.
I am lost.

-- 

Regards
     Stephen

Post a reply to this message

Am 28.10.2016 um 11:35 schrieb Stephen:

>> So this probably doesn't qualify as whatever Mike had in mind when
>> suggesting that "POV-Ray should support point clouds".
> 
> Are you sure we are talking about the same thing?

Pretty much so.

> It seems to me that df3's are point clouds.

Nope. DF3 is a voxel format, which is an entirely different beast.

You can think of a point cloud as just the bare vertices of a mesh, with
no triangles to connect them up. Each point is explicitly specified by
its set of coordinates, and the points are the primary data (although
additional attributes may be associated to them, such as colours). Point
clouds are often used to represent an object's volume by providing
sample points on that object's surface (though there are also measuring
processes that generate data points all across a given volume), and this
type of point cloud data is often the raw output format of
professional-grade 3D scanning devices.

Voxel data, on the other hand, is the 3D equivalent of a pixel image: An
implicit regular grid of "volume pixels" (hence the term) covering a
(typically box-shaped) region in 3D space, and explicit attributes
associated with each and every voxel, with the attribute values
constituting the primary data. That data may represent pretty much
anything: Colour, pressure, heat, wind speed and direction, or whatever.
Representing an object's shape is just one possible application, in
which case each voxel's data will represent what portion of each voxel
falls inside the object's volume. Voxel data is almost always derived
from other input data (such as point clouds).

Post a reply to this message

On 10/28/2016 1:03 PM, clipka wrote:
> Am 28.10.2016 um 11:35 schrieb Stephen:
>
>>> So this probably doesn't qualify as whatever Mike had in mind when
>>> suggesting that "POV-Ray should support point clouds".
>>
>> Are you sure we are talking about the same thing?
>
> Pretty much so.
>
>> It seems to me that df3's are point clouds.
>
> Nope. DF3 is a voxel format, which is an entirely different beast.
>
> You can think of a point cloud as just the bare vertices of a mesh, with
> no triangles to connect them up. Each point is explicitly specified by
> its set of coordinates, and the points are the primary data (although
> additional attributes may be associated to them, such as colours). Point
> clouds are often used to represent an object's volume by providing
> sample points on that object's surface (though there are also measuring
> processes that generate data points all across a given volume), and this
> type of point cloud data is often the raw output format of
> professional-grade 3D scanning devices.
>
> Voxel data, on the other hand, is the 3D equivalent of a pixel image: An
> implicit regular grid of "volume pixels" (hence the term) covering a
> (typically box-shaped) region in 3D space, and explicit attributes
> associated with each and every voxel, with the attribute values
> constituting the primary data. That data may represent pretty much
> anything: Colour, pressure, heat, wind speed and direction, or whatever.
> Representing an object's shape is just one possible application, in
> which case each voxel's data will represent what portion of each voxel
> falls inside the object's volume. Voxel data is almost always derived
> from other input data (such as point clouds).
>

If I understand what you said. Voxel data can be or is a subset of point 
cloud data.

So what is the problem with redefining coordinates in a df3 to points or 
small spheres instead of a cubical volume?

To all intents and purposes the df3s I have made in PovRay. Act like 
point clouds when using emitting media.


-- 

Regards
     Stephen

Post a reply to this message

> If I understand what you said. Voxel data can be or is a subset of point
> cloud data.

Yes, voxel data could just be thought of as point cloud data where all 
the points are on a finite uniform grid (with no empty cells) within 
known limits. In which case it becomes more efficient to store the data 
as a list of values (colour, transparency, whatever) in some agreed 
order, rather than listing the coordinates of every point.

Point cloud data is totally arbitrary, you could have points 1mm apart 
in one area, but points meters apart in others. This is usual if you got 
the data from a laser scanner. The coordinates of each point could be 
anything (within the resolution of the number format you are using), so 
are not on a grid or equally spaced at all.

Think in 2D, voxel data is like a bitmap image, whereas point cloud data 
is like a list of 2D coordinates (perhaps with associated information 
like colour as clipka mentioned).

> So what is the problem with redefining coordinates in a df3 to points or
> small spheres instead of a cubical volume?

My guess is all the algorithms used to render df3's won't work with just 
an arbitrary list of point coordinates.

Post a reply to this message

On 10/28/2016 3:21 PM, scott wrote:
>> If I understand what you said. Voxel data can be or is a subset of point
>> cloud data.
>
> Yes, voxel data could just be thought of as point cloud data where all
> the points are on a finite uniform grid (with no empty cells) within
> known limits. In which case it becomes more efficient to store the data
> as a list of values (colour, transparency, whatever) in some agreed
> order, rather than listing the coordinates of every point.
>
> Point cloud data is totally arbitrary, you could have points 1mm apart
> in one area, but points meters apart in others. This is usual if you got
> the data from a laser scanner. The coordinates of each point could be
> anything (within the resolution of the number format you are using), so
> are not on a grid or equally spaced at all.
>
> Think in 2D, voxel data is like a bitmap image, whereas point cloud data
> is like a list of 2D coordinates


Yes, but how is the list ordered if at all, at all?

(perhaps with associated information
> like colour as clipka mentioned).
>
>> So what is the problem with redefining coordinates in a df3 to points or
>> small spheres instead of a cubical volume?
>
> My guess is all the algorithms used to render df3's won't work with just
> an arbitrary list of point coordinates.
>


I never thought they would. But...
You could turn point cloud data into a df3 by defining a resolution and 
using that to dived the cloud (magically by hard sums) into averaged voxels.

Not that I am asking anyone to implement this.
'Just exploring.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 27.10.2016 um 20:51 schrieb Mike Horvath:
>
> > Also, maybe POV-Ray should support point clouds.
>
> You can always read point cloud data at parse time and convert it to a
> bunch of spheres (or a set of blob elements if you're low on memory).

I know we've touched on this topic, and you've even trimmed down the memory
footprint of the spheres - can you give me a better idea of the memory
difference?  I thought you had previously said there wasn't much of one, but
perhaps I misunderstood exactly what you were saying.

I guess I just have trouble seeing how this

  blob {
    threshold 0.6
      sphere { <.75, 0, 0>, 1, 1 }
      sphere { <-.375, .64952, 0>, 1, 1 }
      sphere { <-.375, -.64952, 0>, 1, 1 }
    }

uses less memory than

      sphere { <.75, 0, 0>, 1 }
      sphere { <-.375, .64952, 0>, 1 }
      sphere { <-.375, -.64952, 0>, 1 }

Post a reply to this message

Am 28.10.2016 um 17:09 schrieb Stephen:

>> Think in 2D, voxel data is like a bitmap image, whereas point cloud data
>> is like a list of 2D coordinates
> 
> Yes, but how is the list ordered if at all, at all?

Exactly that: Not at all.

(There /may/ happen to be /some/ inherent ordering due to the way the
data is acquired, but you can't rely on that.)


> You could turn point cloud data into a df3 by defining a resolution and
> using that to dived the cloud (magically by hard sums) into averaged
> voxels.

Depending on what the point cloud actually represents, you /may/ be able
to use that approach.

If it is just a bare point cloud representing a surface, then there's
obviously nothing to be averaged.

Post a reply to this message