On 8/8/2016 12:13 PM, Bald Eagle wrote:
> Alain <kua### [at] videotronca> wrote:
>
>> Sory, it's just not possible. DF3 support 1, 2 or 3 bytes per voxel, but
>> always in a single channel gray levels.
>
> Given what Stephen resorts to doing...

It is a bit tedious that's true.
It is also very easy to miss out a step.
We really need a simpler method of creating df3s. IIRC there is a 
Proximity Pattern that creates and uses df3s called df3prox-0.95 that 
might be worth looking at.

>
> DISCLAIMER:
> This is all just a pipe-dream that I'm having on a Monday morning, before
> coffee, without inside knowledge of how Moray or Bishop handle data, or how
> DF3's get encoded.
> :)
>
>

What's with the before coffee, thing?
Mad I call you. Mad. :)

By the time you get back from work I should have posted some examples of 
a media filled mesh. I can get it to work after a fashion.

If you are interested I will upload the obj, mtl and image files so you 
can play with them.

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> It is a bit tedious that's true.
> It is also very easy to miss out a step.

Yes.  I am (usually) a big fan of checklists.

> We really need a simpler method of creating df3s. IIRC there is a
> Proximity Pattern that creates and uses df3s called df3prox-0.95 that
> might be worth looking at.

I missed the whole proximity pattern phase of interest and development.
No real idea of what they are, what they do, or how they work.


> By the time you get back from work I should have posted some examples of
> a media filled mesh. I can get it to work after a fashion.
>
> If you are interested I will upload the obj, mtl and image files so you
> can play with them.

Most excellent.

obj is ... Bishop?  Poseray?  both?
is mtl a Moray file?

Post a reply to this message

Am 08.08.2016 um 16:12 schrieb Bald Eagle:

>> If you are interested I will upload the obj, mtl and image files so you
>> can play with them.
> 
> Most excellent.
> 
> obj is ... Bishop?  Poseray?  both?
> is mtl a Moray file?

The `obj` file format is a standardized file format for exchanging mesh
data between different applications.

The `mtl` file format is a standardized companion file format to carry
material information (the `obj` format can only carry material names).

In the POV-Ray ecosystem, Poseray is probably the best way to convert
these files into POV-Ray format.

Post a reply to this message

On 8/8/2016 3:12 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> It is a bit tedious that's true.
>> It is also very easy to miss out a step.
>
> Yes.  I am (usually) a big fan of checklists.
>

Unless something is going to go bang. I am not, I am afraid.

>> We really need a simpler method of creating df3s. IIRC there is a
>> Proximity Pattern that creates and uses df3s called df3prox-0.95 that
>> might be worth looking at.
>
> I missed the whole proximity pattern phase of interest and development.
> No real idea of what they are, what they do, or how they work.
>

The idea is to add dirt/staining to edges, junctions of surfaces etc.
You might be interested in this thread.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.4aa83e6a37d8ab92c83e2c410%40news.povray.org%3E/?mtop=323317

>
>> By the time you get back from work I should have posted some examples of
>> a media filled mesh. I can get it to work after a fashion.
>>
>> If you are interested I will upload the obj, mtl and image files so you
>> can play with them.
>
> Most excellent.
>
I've zipped the dragon and the Lady. Both files are about 5.5 Meg
I'll find a site that I can upload them to and post the link.
Otherwise I can use a site that will post the via email.

I managed to upload the dragon file to povray.binaries.misc
But the other is too large. (5.5 vs 5.7 meg)

> obj is ... Bishop?  Poseray?  both?
> is mtl a Moray file?
>

*.obj is the geometry file, *.mtl is the textures referenced by the obj 
file. Both are text and human readable.

Use PoseRay to convert them to a Pov.inc file.

I had to reduce the resolution of the images or the file size would have 
been > 22 meg.

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> > Yes.  I am (usually) a big fan of checklists.
> Unless something is going to go bang. I am not, I am afraid.

For a while, I was using some organoboranes, organoaluminum, and organozinc
reagents that were air-sensitive and spontaneously pyrophoric.
So there was great potential for "pop"  "Whooooooosssssh"   "BANG"

Others were .... less safety conscious - and it showed.


> The idea is to add dirt/staining to edges, junctions of surfaces etc.
> You might be interested in this thread.
>
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4aa83e6a37d8ab92c83e2c410%40news.povray.org%3E/?mtop=3233
17

Oooh, yes.   That must be the "Edouard Poor" I have heard so much about in
related threads.   I'll definitely have to check those macros out.  They could
add as much or more as radiosity does to a scene.   :)


> *.obj is the geometry file, *.mtl is the textures referenced by the obj
> file. Both are text and human readable.

Got it.  It's been a while.

Post a reply to this message

On 8/8/2016 5:14 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>>> Yes.  I am (usually) a big fan of checklists.
>> Unless something is going to go bang. I am not, I am afraid.
>
> For a while, I was using some organoboranes, organoaluminum, and organozinc
> reagents that were air-sensitive and spontaneously pyrophoric.
> So there was great potential for "pop"  "Whooooooosssssh"   "BANG"
>

Rather you than me. ;)

> Others were .... less safety conscious - and it showed.
>
>
I worked on offshore drilling rigs as an electronic engineer for several 
years.

Q. How do you tell if it is a driller ordering a round of drinks?
A. He will show the barman all his fingers and say three pints of beer.
(Really hard to tell a visual joke on paper.) :)


>> The idea is to add dirt/staining to edges, junctions of surfaces etc.
>> You might be interested in this thread.
>>
>>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4aa83e6a37d8ab92c83e2c410%40news.povray.org%3E/?mtop=3233
> 17
>
> Oooh, yes.   That must be the "Edouard Poor" I have heard so much about in
> related threads.   I'll definitely have to check those macros out.  They could
> add as much or more as radiosity does to a scene.   :)
>
>
Thomas has used it to good effect. I have used it.

>> *.obj is the geometry file, *.mtl is the textures referenced by the obj
>> file. Both are text and human readable.
>
> Got it.  It's been a while.
>

And there are so many TLA (three-letter acronyms) :)

-- 

Regards
     Stephen

Post a reply to this message

> Alain <kua### [at] videotronca> wrote:
>
>> Sory, it's just not possible. DF3 support 1, 2 or 3 bytes per voxel, but
>> always in a single channel gray levels.
>
> Given what Stephen resorts to doing, I thought that might be the case.
>
> BUT - I also thought that perhaps if there were a way to recolor the DF3 befor
> saving, then the realistic RBG values could be _encoded_ into that false color
> in such a way that they could be extracted back out of the gray value.
>

How can you recolor before saving when the format only support discrete, 
single component, scalar values? That's just not possible.

Remember that DF3s have no concept of colour at all. It's strictly a 
list of 1 dimension values.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> How can you recolor before saving when the format only support discrete,
> single component, scalar values? That's just not possible.
>
> Remember that DF3s have no concept of colour at all. It's strictly a
> list of 1 dimension values.

Let me give a different example -
If there is a grayscale value, then that must have some range or depth - how
many values?

If it's like a pattern{}, then you can give it a color_map{}.
My idea here, is instead of having the grayscale represent a range of gray from
0 to Max with 1-unit intervals, have it represent an RGB scale from 0 to Max
_STEP 3_.  It's a lot rougher, but it encodes full color.

Let's say you've got the usual 0-255 values.
That's 8 bits.
pow(2, 8) = 256
let's use 6 of those bytes, 2 for each color channel
granted, that only gives you 4 levels for each channel, but it's rgb - the data
is there.
The trick is getting more than those 4 levels for each channel squeezed into
those 8 bytes.

But I still think it's a better, faster workflow than what Stephen's currently
doing.

I'm sure some very clever folks have ways that can use 8 bits much more
efficiently to store more data.
There certainly seem to be computer-sciency types who have some ideas:

http://stackoverflow.com/questions/3499444/compress-two-or-more-numbers-into-one-byte
http://mathoverflow.net/questions/69244/encoding-n-natural-numbers-into-one-and-back
https://en.wikipedia.org/wiki/Z-order_curve
https://www.google.com/#q=how+to+encode+data+into+one+number

Post a reply to this message

It also occurred to me that one probably doesn't even need to cover the whole
range of RGB values - only the range that's being used, or is significant.

If only certain rgb values are being used, then that a smaller range, and those
few subdivisions represented by the bytes the you have to work with now
represent a much finer scale.

It occurs to me on writing this, that it may be more effective to just ditch RGB
altogether and "encode" the colors in HSV.  Throw out S and V, and just assume
they're both 1, and that leaves you with 360 values.
That gives you a "fineness" of 1.41, which I'm sure is perfectly adequate for
the purpose at hand.

We have some very good people who write POV-Ray source code, and so it would be
a wonderful thing to be ahead of everyone else and have a rapid way of rendering
"full-color" df3 voxels.

The only trick then is to figure out how to get the generating software to write
a scaled hue value rather than a greyscale value.

Sound plausible?

Post a reply to this message

And then there's THIS:

http://news.povray.org/povray.binaries.utilities/thread/%3C4a2870e2%40news.povray.org%3E/?ttop=398992

Post a reply to this message