Le 16-08-07 à 15:31, Stephen a écrit :
> On 8/7/2016 8:12 PM, Alain wrote:
>>>
>>
>> In method 1 and 2, confidence, variance and ratio are used to control
>> how many samples are to be used in the different intervals depending on
>> the density and illumination in the various intervals. With method 3,
>> using more that a single interval is highly counterproductive.
>>
>> I've done my tests with intervals and the negative impact they have on
>> the performance is astounding.
>> I demonstrated that samples 100 is way faster than intervals 10 samples
>> 1 for greatly better results.
>
>
> Thanks Alain, I knew I would get it in the neck for posting that code. :)
> Except for the intervals/samples thing. The other things you mention are
> Bishop3D defaults and there is not a lot that I can do about what is
> exported except go through the code afterwards. But I have a relatively
> fast machine, so I don't.
> I seem to have a blind spot for samples vs intervals. Thomas, amongst
> others, is forever mentioning it.
> I use media so seldom that I have to relearn it whenever I want to use
> it. :(
> So it is not ignorance but stupidity on my part. :(
>

Here are the default vbalues :
method 3
samples 10
intervals 1 // Don't increase !

The default code from Bishop mostly repeat the actual defaults values. 
That effectively make then into "no operation" code.

Even on the fastest machine, using intervals >1 is a serious performance 
killer.


Alain

Post a reply to this message

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


> > used #declare Variable = VRand_In_Obj(object {StanfordDragon}, Stream);
> > to get the coordinates of 10,000 spheres, and placed them, made a copy of that

So, that's a macro where you give it the object, and a random stream, and it
samples the bounding box until it finds a point that's actually IN the object
itself.  So I just did that with a loop 10,00 times.
And I figured media could be faked with tiny spheres - a real point cloud, but
in the shape of the object

> > and overlaid it with a "skin",

I then took the mesh, and textured it with a see-through texture.
I figured if it was just barely visible, it would have a printed-lampshade
effect with the emissive stuff inside - all the color and detail would be on the
outside "skin", and no color separation would be necessary

> plus rendered a jade textured mesh beside it
Just the regular old POV-ray textured mesh object, for comparison

> You are confusing me. You are confusing me with someone who can code. ;)
> Basic and PLC (programmable logic controller) are my limits.

Teamwork.  ;)

> I'll have a look at that. Paul is always worth listening to.

I'm struggling with the crazy camera frustrum thing he has on that page.
Seems like it could rewritten for clarity and completeness.


> Yes you can but in the process of creating a media. PovRay converts the
> colour vector into a scalar. That is why I have used different
> multipliers in the different colour channels.

I will have to think on that.

> > and then maybe overlay the real mesh with a highly-transparent texture.
> That is too simple. There must be a catch. :)

Yeah - I suck at using filter and transmit, and the result might not be as great
looking as a media.

> > Can you make the mesh object filled with a media directly?

Try that.
Put a white emissive media in the mesh container, and texture the mesh with a
very highly transparent texture of the original rgb colors

Post a reply to this message

On 7-8-2016 20:47, Alain wrote:
> If you scale the container with the media, then, that scaling will
> affect any media contained. Emissive media will become brighter,
> absorbing media may become totally opaque.
>
> If you want the media effect to remain unchanged, then you always need
> to adjust the density of the media by the inverse of the scaling. Scale
> up by 10, reduce the density or base colour by 10.

Ah! Thanks for the reminder. I mostly use scattering media that is why.

-- 
Thomas

Post a reply to this message

I was away for part of the day, and now I am lost :-)

I have not followed the media discussion in detail and will pick up from 
here.

-- 
Thomas

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.

I need to get going, so I'll just give a quick non-binary example.
Lets say you had a single "gray value that could range from 0-999.
I was thinking that perhaps R could be factors of 100, G of 10, and B of 1.

3x8=24, 0 to 23, pow(2, 23) =
8388608

Simplistic, and it all depends on how the gray value gets calculated so that
things don't get irreversibly "mixed" - but I'll bet the 8-bit guys would puzzle
out a clever cryptographic scheme to encode all of Tetris into that little bit
of storage space  ;)

If it's possible, the range of RGB of course will not be as smooth as the
original, but I believe the trade-off in saving Stephen many painful hours of
scene development would be well worth it.

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.
:)

Post a reply to this message

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