> Stephen <mca### [at] aolcom> wrote:
>> I use three media in one interior.
>
> Changed my code - that seems to work for me now.
>
>> I would post the code but it is messy. I have to overwrite the code
>> Bishop3d exports with the code modified to run direct from Pov.
>
> Seems messy and time consuming.
>
>> Both Bishop3d and Moray export a pov file for each frame and it takes
>> PovRay 16 seconds to save the scene.
>
> "Frame"?  Is that one of the "slices" to make the DF3?
>
>> Creating the tga files to make the
>> df3's would take Bishop3d about an hour and a half to export 100 frames
>> times 3 for each channel.
>
> That seems insane.
>
> There has to be a better way / workflow.
>
> I had an idea last night -
> I did a quick experiment with the Stanford Dragon mesh:
> defined the object
> 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
> and overlaid it with a "skin", plus rendered a jade textured mesh beside it - in
> 51 seconds.
>
> I'm thinking that it may be well worth your while to either ditch media and use
> an alternate scheme, or use POV-Ray to scan through a full-color solid object
> and make a point-cloud right in SDL
>
> http://paulbourke.net/miscellaneous/povexamples/
>
> I think there must be a way to export the full RGB data in a single DF3, and
> then maybe overlay the real mesh with a highly-transparent texture.

Sory, it's just not possible. DF3 support 1, 2 or 3 bytes per voxel, but 
always in a single channel gray levels.

>
> Can you make the mesh object filled with a media directly?
>
> I don't play with these things very often, so I'm just brainstorming.
>
>

Post a reply to this message

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

-- 

Regards
     Stephen

Post a reply to this message

On 8/7/2016 8:00 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>> I use three media in one interior.
>
> Changed my code - that seems to work for me now.

Good, good.

>
>> I would post the code but it is messy. I have to overwrite the code
>> Bishop3d exports with the code modified to run direct from Pov.
>
> Seems messy and time consuming.
>

True but needs must. :) And I need a visual representation of the scene 
I am making.

>> Both Bishop3d and Moray export a pov file for each frame and it takes
>> PovRay 16 seconds to save the scene.
>
> "Frame"?  Is that one of the "slices" to make the DF3?

Yes, I use frame_number instead of clock for animations.
>
>> Creating the tga files to make the
>> df3's would take Bishop3d about an hour and a half to export 100 frames
>> times 3 for each channel.
>
> That seems insane.
>
> There has to be a better way / workflow.

You are telling me. It is so easy to make a mistake or forget a step.
Very tiresome indeed.

>
> I had an idea last night -
> I did a quick experiment with the Stanford Dragon mesh:

I had forgotten about the Stanford Dragon. It is quite upright at the 
front and might be a good object to use. The Stanford Bunny might be a 
good model to use as well. If you can imagine a drug smoking violent 
Street Gang disguised as bunny.

> defined the object
> 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
> and overlaid it with a "skin", plus rendered a jade textured mesh beside it - in
> 51 seconds.
>

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

> I'm thinking that it may be well worth your while to either ditch media and use
> an alternate scheme, or use POV-Ray to scan through a full-color solid object
> and make a point-cloud right in SDL
>
> http://paulbourke.net/miscellaneous/povexamples/
>

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

> I think there must be a way to export the full RGB data in a single DF3,

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.

> and then maybe overlay the real mesh with a highly-transparent texture.
>

That is too simple. There must be a catch. :)

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

If I make sure that the mesh is closed. I don't want my dragon leaking :)

It would negate the problem of a media container inside another media 
container being visible.

> I don't play with these things very often, so I'm just brainstorming.
>
>
Keep at it. It is only too easy to pick one direction and stick to it.
Almost all comments are welcome.

-- 

Regards
     Stephen

Post a reply to this message

On 8/7/2016 8:16 PM, Alain wrote:
>> I think there must be a way to export the full RGB data in a single
>> DF3, and
>> then maybe overlay the real mesh with a highly-transparent texture.
>
> Sory, it's just not possible. DF3 support 1, 2 or 3 bytes per voxel, but
> always in a single channel gray levels.

That is why I filtered the R, G & B values then copied the single colour 
to the other colours in an editor. It did not work as well as I hopped. 
But some of the detail is there.

-- 

Regards
     Stephen

Post a reply to this message

On 8/7/2016 8:00 PM, Bald Eagle wrote:
> then maybe overlay the real mesh with a highly-transparent texture.

Just had another thought about that idea.
Poser meshes are not like scanned meshes. They can have internal 
structures. For instance eyes are closed meshes part of which is within 
the whole body. In the animation below the eyes of the spirit Ariel's 
eyes glow. An artefact that did not distract, for once. :)

http://www.tc-rtc.co.uk/image/upload//Stephen/pw-1228515119-Prologue.mpg

-- 

Regards
     Stephen

Post a reply to this message

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