clipka <ano### [at] anonymousorg> wrote:
> Can you be more specific about the scene "crashing"?
>
> I do notice a pause between parsing and the start of the render,
> probably related to the many warning messages your scene produces, but
> after a few seconds the render does proceed.
>
> You can avoid the warning messages (and the unexpected pause) by
> replacing "ambient 0.5" with "emission 0.5" in the "Fire_Texture" macro,
> or by using "#version 3.6" instead of "#version 3.7".

You are right, I was too impatient, there is no crashing.
First I replaced "ambient" by "emission", so getting rid of all messages.
Then the SDL parses correctly and rendering starts after some seconds.
The generated object are counted-up in the status line, so everything is fine.

You are also right, the pausing is caused by the warning messages.
To provoke this effect even more, I left the "ambient" and added a few lines of
"#render" within the recursion loop containing a long string with bad
characters. This caused -really- many warnings!

The effect on the GUI is very similar to a crash.
After pressing "Run" warning messages start to list up in the bottom status
line. After 2-3 seconds, the status line freezes. If I then try to switch to the
"Messages" Tab, the entire GUI freezes, the cursor starts to spin and the window
is saying "not responding".
However, if I check the status of the CPU cores, I see that all are fully in
use, which is a sign that rendering has started already. During parsing just a
single core is used. So obviously parsing has finished, rendering has started,
but the GUI is still hanging and busy with warning message output.

After provoking such many warning messages, this state of freeze lasted about 30
seconds, after that the GUI recovers and jumps immediately to showing the render
progress, and there is it also obvious that rendering has taken place during the
freeze state.

I tried the trick with using the unsupported #render / #statistic console output
pipe also with v3.7 and the effect was the same, so this issue seems to be not
new in this beta.

I have a pretty fast CPU, and if just one of the cores is used (which is the
case for parsing) the core goes into turbo mode at higher clock-rates. So my
guess would be that the parser generates the warning triggers faster than the
GUI console can output them, in particular if the warning string is long, which
is the case for the "ambient" warning. An additional problem is that rendering
is started using all cores, so the core used for the GUI and the message output
is pushed into its limit by the additional load from the rendering thread,
causing the freeze state to be even longer.

So no crash, but the effect looks very similar and an impatient user will not
wait but kill the window immediately. In times of fast CPUs, maybe the thread
distribution has to be reconsidered?

BR Billabong

Post a reply to this message