 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 29/09/2013 14:38, Le_Forgeron nous fit lire :
> Le 29/09/2013 14:27, Thomas de Groot nous fit lire :
>> On 29-9-2013 14:02, Thomas de Groot wrote:
>>
>>> Question: If the df3 are made to a unit-sized box, why does the x-axis
>>> need a correction different from object to object?
>>
>> A tentative answer to the question:
>>
>> Could it be that the image format in which the tga slices are rendered
>> influences the final result? In other words, should objects be rendered
>> using a /square/ image format (1:1 ratio) in the first place? I blindly
>> followed Gilles Tran's advice to use a 1.33 ratio. This might be
>> irrelevant for clouds but not for other objects...
>>
>> Thomas
>>
> Do we have the sources of tga2df3 ?
>
Oki, found in groups a source of tga2df3... it might be time to get
something like png2df3 because the expected tga format is rather limited
and unchecked: targa true color, 8 bits per channel, no alpha, and only
version 1
The pictures are processed as z (the further frame, the deeper),
top left/ top right to bottom right become <0,0>/<0,1> to <1,1> (hence
the -1 factor needed on y in scale for scene)
All pictures must be the same size, but ratio is irrelevant: the
resolution of the picture is transposed to the x,y resolution (or rather
precision) of the df3 file.
The pattern itself consider only the <0,0,0> to <1,1,1> cube, then
computes the cell(s) to use by applying the df3 resolution to get the
indexes on each axis. (some interpolation might wrap as an hypertorus on
the border of the cube: left side is connected to right side, top with
bottom and front with rear, for trilenear interpolation only)
What remains could be the sampling applied on the pattern.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.09.2013 14:27, schrieb Thomas de Groot:
> On 29-9-2013 14:02, Thomas de Groot wrote:
>
> Could it be that the image format in which the tga slices are rendered
> influences the final result? In other words, should objects be rendered
> using a /square/ image format (1:1 ratio) in the first place? I blindly
> followed Gilles Tran's advice to use a 1.33 ratio. This might be
> irrelevant for clouds but not for other objects...
>
Gilles used in his demo a 512x384 pixel resolution, therefor a = 1.333
ratio (512/384 = 1.33...).
When you use another resolution also another scaling is required. The
same goes for the scaling in the z-direction, it depends on the the
number of slices you have produced in relation to the image dimension.
Years ago I've written a little C program that did work with 16bit png
images as input format for producing df3-files (I used it for some
stellar nebulae) and it did in addition spit out the required POV-Ray
scaling to keep the original proportions. Sadly I do not find it anymore
(and worst: not its source) but as it is really trivial I might do it
again...
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29-9-2013 16:05, Ive wrote:
> Am 29.09.2013 14:27, schrieb Thomas de Groot:
>> On 29-9-2013 14:02, Thomas de Groot wrote:
>>
>> Could it be that the image format in which the tga slices are rendered
>> influences the final result? In other words, should objects be rendered
>> using a /square/ image format (1:1 ratio) in the first place? I blindly
>> followed Gilles Tran's advice to use a 1.33 ratio. This might be
>> irrelevant for clouds but not for other objects...
>>
> Gilles used in his demo a 512x384 pixel resolution, therefor a = 1.333
> ratio (512/384 = 1.33...).
> When you use another resolution also another scaling is required. The
> same goes for the scaling in the z-direction, it depends on the the
> number of slices you have produced in relation to the image dimension.
>
> Years ago I've written a little C program that did work with 16bit png
> images as input format for producing df3-files (I used it for some
> stellar nebulae) and it did in addition spit out the required POV-Ray
> scaling to keep the original proportions. Sadly I do not find it anymore
> (and worst: not its source) but as it is really trivial I might do it
> again...
>
> -Ive
>
After testing the skeleton with a 1:1 ratio tga slices:
To Le_Forgeron:
Ratio /is/ relevant in so far that it changes the x-axis scale factor.
For the skeleton the factor changes from 3 (1.333 ratio) to 2.2 (1:1 ratio).
To Le_Forgeron & Ive:
A new conversion program seems indeed to be in need...
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28-9-2013 17:23, MichaelJF wrote:
> I can only guess your problem, but I think you are missing some structure (e.g.
> the ribs) here.
To answer to this particular point: Increasing the samples in the media
does the trick. I need at least 200 to get it right.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> On 28-9-2013 17:23, MichaelJF wrote:
> > I can only guess your problem, but I think you are missing some structure (e.g.
> > the ribs) here.
>
> To answer to this particular point: Increasing the samples in the media
> does the trick. I need at least 200 to get it right.
>
> Thomas
Thanks for the hint, sometimes one overlooks the obvious. I just made a notice
to rerender my "Eruption" image with higher samples next days. I had only 100
there but df3-files with 1024^3 voxels (some 1 GByte each) and in certain areas
where I know that there is density nothing appeared.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 29/09/2013 16:34, Thomas de Groot a écrit :
>
> After testing the skeleton with a 1:1 ratio tga slices:
>
> To Le_Forgeron:
> Ratio /is/ relevant in so far that it changes the x-axis scale factor.
> For the skeleton the factor changes from 3 (1.333 ratio) to 2.2 (1:1
> ratio).
what is the original ratio of the skeleton ? (before rendering as tga)
Remember that the df3 file will fit everything in a 1x1x1 box, so if the
original box of the skeleton is not similar, its ratio must be take into
account (and the intermediate tga ratio only add more term to the equation).
--
Just because nobody complains does not mean all parachutes are perfect.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30-9-2013 8:39, Le_Forgeron wrote:
> what is the original ratio of the skeleton ? (before rendering as tga)
>
> Remember that the df3 file will fit everything in a 1x1x1 box, so if the
> original box of the skeleton is not similar, its ratio must be take into
> account (and the intermediate tga ratio only add more term to the equation).
>
From the mesh2 file generated by Poseray:
//Bounding Box....... from x,y,z=(-0.1472,-0.005,-0.06045)
// to x,y,z=(0.1423,0.6241,0.1716)
// size dx,dy,dz=(0.2895,0.6291,0.23205)
// center x,y,z=(-0.00245,0.30955,0.055575)
// diagonal 0.730359
Obviously, these values are identical to the ones calculated with min_
and max_extent. ;-)
Using the size to re-scale the df3 works fine - and in every case - for
the y-axis and the z-axis. So, what happens to the x-axis? Even in a 1:1
ratio?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29-9-2013 18:01, MichaelJF wrote:
> Thanks for the hint, sometimes one overlooks the obvious. I just made a notice
> to rerender my "Eruption" image with higher samples next days. I had only 100
> there but df3-files with 1024^3 voxels (some 1 GByte each) and in certain areas
> where I know that there is density nothing appeared.
Something else which I just discovered by chance. Scaling the container
in which the media is put to the original object's bounding box, reduces
dramatically the number of samples needed. Initially, I used a standard
box{-1,1} and needed at least 300 to 400 samples for the skeleton. Now I
used box{Min,Max translate Center} and only need 50 samples!
Thomas
Post a reply to this message
Attachments:
Download 'gt_df3_test.png' (58 KB)
Preview of image 'gt_df3_test.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/30/2013 04:00 AM, Thomas de Groot wrote:
> On 29-9-2013 18:01, MichaelJF wrote:
> dramatically the number of samples needed. Initially, I used a standard
> box{-1,1} and needed at least 300 to 400 samples for the skeleton. Now I
> used box{Min,Max translate Center} and only need 50 samples!
>
Makes sense, but I'd not thought to do it. Thanks for the tip.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30-9-2013 12:52, William F Pokorny wrote:
> Makes sense, but I'd not thought to do it. Thanks for the tip.
Neither did I think of the implications. It came to me that reducing the
container to its bare minimum might help reduce render time but I had
not thought about the impact on the samples.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
