Op 15/08/2020 om 08:22 schreef Thomas de Groot:
> Right! I shall try on my side to see if there is a difference when 
> radiosity data is saved in the scene.
> 

Did a test: not better, maybe even worse!

-- 
Thomas

Post a reply to this message

Attachments:
Download 'continueissue_grey_2.jpg' (24 KB)

Preview of image 'continueissue_grey_2.jpg'

Op 15/08/2020 om 08:51 schreef Thomas de Groot:
> Op 15/08/2020 om 08:22 schreef Thomas de Groot:
>> Right! I shall try on my side to see if there is a difference when 
>> radiosity data is saved in the scene.
>>
> 
> Did a test: not better, maybe even worse!
> 

Question: /where/ is the radiosity data file saved??? I am unable to 
find it anywhere...

I assumed it was into the same folder as the scene.

-- 
Thomas

Post a reply to this message

Op 15/08/2020 om 09:09 schreef Thomas de Groot:
> Op 15/08/2020 om 08:51 schreef Thomas de Groot:
>> Op 15/08/2020 om 08:22 schreef Thomas de Groot:
>>> Right! I shall try on my side to see if there is a difference when 
>>> radiosity data is saved in the scene.
>>>
>>
>> Did a test: not better, maybe even worse!
>>
> 
> Question: /where/ is the radiosity data file saved??? I am unable to 
> find it anywhere...
> 
> I assumed it was into the same folder as the scene.
> 

Well... Not sure what happens but somehow /reading/ (+RFI) makes the 
render to fail when restarting. I do not completely understand the use 
of RF from the explanation in the wiki.

I tested this time in version 3.7.1 with identical results as 3.8.

-- 
Thomas

Post a reply to this message

On 8/15/20 3:27 AM, Thomas de Groot wrote:
> Op 15/08/2020 om 09:09 schreef Thomas de Groot:
>> Op 15/08/2020 om 08:51 schreef Thomas de Groot:
>>> Op 15/08/2020 om 08:22 schreef Thomas de Groot:
>>>> Right! I shall try on my side to see if there is a difference when 
>>>> radiosity data is saved in the scene.
>>>>
>>>
>>> Did a test: not better, maybe even worse!
>>>
>>
>> Question: /where/ is the radiosity data file saved??? I am unable to 
>> find it anywhere...
>>
>> I assumed it was into the same folder as the scene.
>>
> 
> Well... Not sure what happens but somehow /reading/ (+RFI) makes the 
> render to fail when restarting. I do not completely understand the use 
> of RF from the explanation in the wiki.
> 
> I tested this time in version 3.7.1 with identical results as 3.8.
> 
Thanks for digging. Remembering now something like radiosity's save and 
load got moved to flag/ini control (v3.7 to v3.8 ?) while the photon 
load and save did not.

Aside: I got no errors (or saved radiosity file) using save_file, 
load_file in the radiosity block which, in the moment, allowed me to 
think the changes and state were the other way around.

Aside 2: There is the +hr and vain pretrace radiosity stuff too. For 
exact image compares when running radiosity I've always had to drop back 
to one thread.

I'm not a big radiosity user, but I'll play a little with the flags 
while my coffee brews and post if I figure more out.

Bill P.

Post a reply to this message

On 8/15/20 5:42 AM, William F Pokorny wrote:
> On 8/15/20 3:27 AM, Thomas de Groot wrote:
...
> 
> I'm not a big radiosity user, but I'll play a little with the flags 
> while my coffee brews and post if I figure more out.
> 

OK. I found to create/save radiosity results I had to use "+rfRad.sav 
+rfo". To use the samples I had to use "+rfRad.sav +rfi".

Further, as shown in the top row of the attached image the "+rfRad.sav 
+rfo" result on the left is not identical to the "+rfRad.sav +rfi" 
results in the middle. Any two +rfo, +rfi renders are identical.

The perhaps helpful news, when comparing a complete "+rfRad.sav +rfi" 
render on the left bottom to one which had be stopped and continued 
every two render block rows in the bottom middle, the results are 
closer. The issue is still there, but the effect is not as pronounced.

This is with your radiosity block - always sample is off. It looks as if 
even loading radiosity samples some radiosity calculation / smaller 
number of rays are shot. Didn't explore whether there was some way to 
better suppress some/all of these and so get a closer match on continuation.

If you're using radiosity and think you might stop and start your 
render, using save radiosity samples is for that render is better, but 
not a complete fix/workaround.

Bill P.

Post a reply to this message

Attachments:
Download 'continueradsavbetter.jpg' (389 KB)

Preview of image 'continueradsavbetter.jpg'

Op 15/08/2020 om 13:02 schreef William F Pokorny:
> 
> OK. I found to create/save radiosity results I had to use "+rfRad.sav 
> +rfo". To use the samples I had to use "+rfRad.sav +rfi".

Ah! So it is the .sav extension that is mandatory. I used .inc but that 
did not work apparently. The wiki is silent about this and I think it 
should be mentioned there and wherever the .sav is needed. The use of 
+rfo and +rf1 in this context also needs some more explanation.

> 
> Further, as shown in the top row of the attached image the "+rfRad.sav 
> +rfo" result on the left is not identical to the "+rfRad.sav +rfi" 
> results in the middle. Any two +rfo, +rfi renders are identical.

OK. Having done a bit of experimentation of my own now, I see that using 
"+rfRad.sav +rfo" for the first run, and then "+rfRad.sav +rfo +rfi" for 
all continuations, results in a - visually - seamless render (see 
attachment where I continued several times randomly). VERY good indeed! 
Thanks Bill, for this insight.

> 
> The perhaps helpful news, when comparing a complete "+rfRad.sav +rfi" 
> render on the left bottom to one which had be stopped and continued 
> every two render block rows in the bottom middle, the results are 
> closer. The issue is still there, but the effect is not as pronounced.
> 
> This is with your radiosity block - always sample is off. It looks as if 
> even loading radiosity samples some radiosity calculation / smaller 
> number of rays are shot. Didn't explore whether there was some way to 
> better suppress some/all of these and so get a closer match on 
> continuation.
> 
> If you're using radiosity and think you might stop and start your 
> render, using save radiosity samples is for that render is better, but 
> not a complete fix/workaround.
> 

Indeed, but as I said above, visually, the render /looks/ faultless and 
this is a workable solution.

Thanks again indeed for your help, Bill. I am glad we brought this 
little bug to light.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'continueissue_grey_3.jpg' (55 KB)

Preview of image 'continueissue_grey_3.jpg'

And so we reach the final scene.

The two isosurfaces (see p.t.scene-files) are superposed.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'into the wild_final2.png' (887 KB)

Preview of image 'into the wild_final2.png'

Thomas de Groot wrote on 02/09/2020 08:31:
> And so we reach the final scene.
> 
> The two isosurfaces (see p.t.scene-files) are superposed.
> 

Really a great image!

  Paolo

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> And so we reach the final scene.
>
> The two isosurfaces (see p.t.scene-files) are superposed.
>

That looks really good. I certainly like the 'fuzzy vegetation' effect; well
done! And thanks for posting the code.

Post a reply to this message

Op 02/09/2020 om 20:08 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> And so we reach the final scene.
>>
>> The two isosurfaces (see p.t.scene-files) are superposed.
>>
> 
> That looks really good. I certainly like the 'fuzzy vegetation' effect; well
> done! And thanks for posting the code.
> 
> 

Thanks indeed, Paolo and Kenneth.

The fuzzy vegetation code was a chance hit :-) and it is as fast (or as 
slow) to render as the rocky part. Overall, while I like isosurfaces to 
build landscapes, I am reluctant to use them because of their slow 
render speed, although I do not complain for this particular one. But if 
you want to complete the landscapes with vegetation, dwellings, roads 
and such, the testing time becomes prohibitive indeed.

-- 
Thomas

Post a reply to this message