Op 14/05/2021 om 23:38 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I guess we should discuss the macro here, as images will be important items.
>>
>> The macro can be found in p.b.s-f
> 
> had a brief first look.  it will be difficult to discuss fully, in isolation, I
> guess, because various prefixes imply a place in a greater schema.  one
> immediate thing though is comments within the macro code/body, I have learned
> from 'Foreach()' that moving comments out of the code does improve performance.
> 
About the comments: yes I guess you are right; moving them should be 
done indeed /before/ the final version and included into the Docs file. 
Noted.

-- 
Thomas

Post a reply to this message

Op 14/05/2021 om 14:20 schreef Thomas de Groot:
> The macro can be found in p.b.s-f
> 
Already the first corrections implemented! Beta #1.1 has been uploaded.

-- 
Thomas

Post a reply to this message

Op 14/05/2021 om 23:38 schreef jr:
> had a brief first look.  it will be difficult to discuss fully, in isolation, I
> guess, because various prefixes imply a place in a greater schema.  one
> immediate thing though is comments within the macro code/body, I have learned
> from 'Foreach()' that moving comments out of the code does improve performance.
> 
My idea is/was that users simply try the different possibilities in 
their own environment, primarily for usefulness in their own scenes, 
like Dave Blandston has done. I guess that questions about the 
/structure/ will come automatically, like yours about the "greater 
scheme" (short answer: there isn't!). Those will probably lead to, e.g., 
name simplifications.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 14/05/2021 om 14:20 schreef Thomas de Groot:
>> The macro can be found in p.b.s-f
> Already the first corrections implemented! Beta #1.1 has been uploaded.

grabbed an old (comparison) scene, just for a quick test, hope to find time (and
a more interesting shape) to begin explore (some of) the settings.  the
animation is just over the 5M limit, so have attached a frame.

on the first run the alpha.10064268 crashed at frame #46, something about a
doubly-linked list, but re-running with 'script' didn't reproduce.

fwiw, needed to add a second light source because I thought the image a little
dark, that quadrupled the per frame render time.  :-)


regards, jr

Post a reply to this message

Attachments:
Download 'icosa_anim_07.png' (352 KB)

Preview of image 'icosa_anim_07.png'

Op 15/05/2021 om 18:33 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 14/05/2021 om 14:20 schreef Thomas de Groot:
>>> The macro can be found in p.b.s-f
>> Already the first corrections implemented! Beta #1.1 has been uploaded.
> 
> grabbed an old (comparison) scene, just for a quick test, hope to find time (and
> a more interesting shape) to begin explore (some of) the settings.  the
> animation is just over the 5M limit, so have attached a frame.
> 
This looks very good indeed! The objects look smooth and a bit rough at 
the same time: the normals do their job as they should!

> on the first run the alpha.10064268 crashed at frame #46, something about a
> doubly-linked list, but re-running with 'script' didn't reproduce.
> 
> fwiw, needed to add a second light source because I thought the image a little
> dark, that quadrupled the per frame render time.  :-)
> 
That could be expected indeed. The macro is not very animation-friendly :-)

> 
> regards, jr
> 


-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 15/05/2021 om 18:33 schreef jr:
> > ...
> > a more interesting shape) to begin explore (some of) the settings.  ...
>
> This looks very good indeed! The objects look smooth and a bit rough at
> the same time: the normals do their job as they should!

thanks.  not my doing.  :-)  both objs textured with your default.


> > fwiw, needed to add a second light source because I thought the image a little
> > dark, that quadrupled the per frame render time.  :-)
> >
> That could be expected indeed. The macro is not very animation-friendly :-)

still, a massive increase, and, for me ("numpty") an unexpected "surprise".
perhaps a sentence or two in the documentation, regarding the .. sensitivity to
the environment.


regards, jr.

Post a reply to this message

Op 16-5-2021 om 12:45 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 15/05/2021 om 18:33 schreef jr:
>>> ...
>>> a more interesting shape) to begin explore (some of) the settings.  ...
>>
>> This looks very good indeed! The objects look smooth and a bit rough at
>> the same time: the normals do their job as they should!
> 
> thanks.  not my doing.  :-)  both objs textured with your default.
> 
> 
>>> fwiw, needed to add a second light source because I thought the image a little
>>> dark, that quadrupled the per frame render time.  :-)
>>>
>> That could be expected indeed. The macro is not very animation-friendly :-)
> 
> still, a massive increase, and, for me ("numpty") an unexpected "surprise".
> perhaps a sentence or two in the documentation, regarding the .. sensitivity to
> the environment.
> 
I am just thinking aloud here, but I wonder /what/ makes the render time 
quadruple? I shall make some test on my side too, because I don not 
entirely understand the phenomenon.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...
> I am just thinking aloud here, but I wonder /what/ makes the render time
> quadruple? I shall make some test on my side too, because I don not
> entirely understand the phenomenon.

no idea whether this info is any help.  the scene was, apart from added
light_source, the same.  both objects are a 'mesh2' type, the one on the right
with ("weighted average") normal_vectors.


regards, jr.

Post a reply to this message

Op 16-5-2021 om 14:19 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> ...
>> I am just thinking aloud here, but I wonder /what/ makes the render time
>> quadruple? I shall make some test on my side too, because I don not
>> entirely understand the phenomenon.
> 
> no idea whether this info is any help.  the scene was, apart from added
> light_source, the same.  both objects are a 'mesh2' type, the one on the right
> with ("weighted average") normal_vectors.
> 
It is strange. The attached image is a simple scene with a mesh2 object 
(twice). A first render with only one light source took 8m39s; a second, 
with an added shadowless light, took 8m52s; a third render (attached) 
with the second light /not/ shadowless, took 10m20s.

We are far from a quadruple render time... I have no idea.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'granitetest.jpg' (78 KB)

Preview of image 'granitetest.jpg'

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...
> It is strange. The attached image is a simple scene with a mesh2 object
> (twice). A first render with only one light source took 8m39s; a second,
> with an added shadowless light, took 8m52s; a third render (attached)
> with the second light /not/ shadowless, took 10m20s.
>
> We are far from a quadruple render time... I have no idea.

I wonder whether the normal vectors in the rightmost object somehow ..
interfere.  no idea, have attached the code I use.  nearly forgot - the
output_file_names in the ini file will need adjusting.


regards, jr.

Post a reply to this message

Attachments:
Download 'tdg_tst_beta.zip' (3 KB)