ui_scalar freeze on MS/Windows only

[Loïc Fejoz]

Hi Sylvain and team,

When changing ui_scalar, I got a freeze very easily on MS/Windows with 2.1.11-beta1 and an Geforce GTX970, either IceSL-Forge or IceSL-Slicer, with this model:
https://github.com/loic-fejoz/loic-fejoz-fabmoments/blob/master/generative-tree/generative-tree.lua

Moreover the "seed" ui_scalar it not working at all, but changing the radius does work (before freezing).

It works properly under Linux.

regards,
Loïc

[Re-try WhenDown]

(line 63) seed = ui_scalar('seed', 0, 1024, 1)

you're wrongly using ui_scalar, it shoulb be:

seed = ui_scalar('seed', 1, 1, 1024)

(line 40) emit(translate(state.origin) * sphere(radius), state.brush)

you're using 'emit' inside a recursive tree function that is gonna be called god knows how many times. Each emit does a union of the shape being emitted with the ones already emitted. There's a limit to union (e.g. lower the initial branching to 20 and it works fine, at least in my pc)

I suggest you save the whole shape a-priori in each calculation with a merge operation. If you wanna keep the ui to change this on the spot, you have to sacrifice changing parameters via UI that will change the whole tree calculation.

Salim.

--
You received this message because you are subscribed to the Google Groups "IceSL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icesl+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Loïc Fejoz]

 Hi,

Thanks Salim for having catch the ui_scalar miss-usage.
It is indeed not the first time that I got it wrong. But still, you (the team) should make sure such a miss-usage does not make IceSL freeze.
For instance, why the hell having a default  value not in the range may freeze the UI?  At least add a Lua assertion to make it clear in the console...
By the way, I always think of the ui_scalar as ui_scalar(min, max, step) (like a loop in any programing language) and not ui_scalar(default, min, max). It is really annoying to have float instead of integer in the UI.

Regarding the max limit to union, I know it quite well after encountering it several time. Thanks.
NB : 50 branching on my machine is proper ...depending on the other parameters. And you do not need to be god to compute an upper-bound! (@_@)

Anyway, this model was done on earlier IceSL version and working, I just add the seed ui_scalar to make it easier to test various configurations.
Moreover I will show you at the IceSL event another version of this one that will not suffer the union limit because of something else nicer :-D

regards,
Loïc

[sylefeb]

Hi Loic,

I agree we have to make the script interpreter more robust to "out-of-bounds" cases. This is high on our list actually (for the next few weeks we are going to lower our technical debt in some areas, this is one of them).
Recursions: I remember Salim and I looked into that at some point, and there are tricky aspects to catching them properly (due to lua integration). But surely it can be done.

Thanks for the report+script - this is going to serve as a good test :)

Best,
Sylvain

[Loïc Fejoz]

Hi Sylvain,

+1 for the robustness. Should we bet on how freeze or segfault you will on the D day? ;-)
Just joking.

For the recursion, you should not worry about it IMHO. Even in my case which is pretty recursive heavy, I do not encounter the limit (and never has). Do you?
The union limit handling is much higher in priority I think.
Moreover my recursive examples are easily linearisable if needed.

Anyway I will show you later, the same model that generate an implicit_distance_field with just the same syntax. But, at the end, I am not applying an union (or merge) but a blend: this is much nicer.

regards,
Loïc

[sylefeb]

> Should we bet on how freeze or segfault you will on the D day? ;-)

Zero will be our goal in any case, but I am not ready to bet yet ;-)

generate an implicit_distance_field with just the same syntax

Sounds great. One thing to brainstorm is how to make it easier to interop between implicit shapes. I have a couple ideas we can discuss during the meeting 

Basically if doing "union(a,b)" where a and b are implicits, we could generate implicit code on the fly to produce the union -- this way we could have cool blends -- like the smooth one -- integrated. We could also convert non-implicits into distance fields on the fly. Some cases like spheres and cylinders are trivial, for meshes a (narrow band) distance field has to be produced which is somewhat tricky for performance but could be cached.

Sylvain

 

[Loïc Fejoz]

Hi,

I don't know how far you should integrate within IceSL, and how much should be user defined...

Download both files generative-tree-sd.lua and sd-icesl.lua from https://github.com/loic-fejoz/IcestoneSL/tree/master/src/main/lua

I can user-defined exactly what you said in your previous answer (except for mesh that I do not use at all).

Loïc

[sylefeb]

Very very nice. Indeed, you are right, maybe this should be left to the user. It is one strength of IceSL + lua that you can do this.

Actually, with Salim we decided to strongly reduce the number of native lua/c++ functions and to transfer most into a 'standard' lua library of functions. This 'standard' library will be programed in lua, available on github, and will be available to all scripts. It will re-implement all current functionalities from a reduced set of core functions.

This will probably turn into a "icesl-libraries" repository with several libs that can be loaded into scripts.

Cool stuff!
Sylvain