FW: limit to number of elements rendered in a single operation
Hi David,
You are registered without the '+.', that was after sending the message below. So I'm replying to
get it on the list. (I also Bc'd you in case)
As I mentioned, I think the community would be happy to extend the limit, as it was somewhat
arbitrary.
Let the debate begin, how big is big enough, or maybe make it an advanced preference, just like the
cache size/render limits?
Reply to this (discuss version) to see if it's working.
Michael
From: David C
Sent: Saturday, 25 February 2017 4:32 AM
To: discuss@lists.openscad.org
Subject: limit to number of elements rendered in a single operation
I was creating some test code for a library I'm writing for OpenSCAD, and ran into an interesting
limitation. When I attempted to render a list of 3D points as cubes, if the list was >=10,000
elements in size, OpenSCAD throws an error. If I created two separate lists of points, each
<10,000, and rendered the lists in two separate operations, OpenSCAD doesn't throw an error and
draws the result just fine.
I can't seem to find any documentation as to why this limit exists, or if it is just a hard-coded
sanity check against someone trying to render something with too many elements. Given there is a
work-around of just splitting up the job, I could write a function that checks the size of the list
I'm about to generate, and split it up if it is too big, but this complicates things with
referencing subset groups in the list if the elements are spread across multiple list variables.
The following code works, and will render correctly. Change randomSpherePoints(9999) to
randomSpherePoints(10000) and an error will happen.
// plot a set 3D of points using cubes of adjustable side-length
module list_plot(points,cube_size=0.01){
for(i = [0:1:len(points)-1]) {translate(points[i]) cube(cube_size);}
}
// Spherical (r,theta,phi) to Cartesian (x,y,z) coordinate transformation
// source: Mathematical Methods for Scientists and Engineers - Donald A. McQuarrie
// x = r*cos(phi)*sin(theta)
// y = r*sin(phi)*sin(theta)
// z = r*cos(theta)
//
// 0 <= r < infinity
// 0 <= theta <= Pi (180 degrees)
// 0 <= phi <= 2*Pi (360 degrees)
// *_sphere_degrees functions take angle arguments in degrees
function x_sphere_degrees(r=1,theta=0,phi=0) = r*cos(phi)*sin(theta);
function y_sphere_degrees(r=1,theta=0,phi=0) = r*sin(phi)*sin(theta);
function z_sphere_degrees(r=1,theta=0) = r*cos(theta);
function xyz_from_sphere(r=1,theta=0,phi=0) = [x_sphere_degrees(r,theta,phi),
y_sphere_degrees(r,theta,phi), z_sphere_degrees(r,theta)];
// random_sphere_point() generates a pseudo-random point lying on a sphere of non-random radius "r"
function random_sphere_point(r=1) =
xyz_from_sphere(r,theta=rands(0,180,1)[0],phi=rands(0,360,1)[0]);
// randomSpherePoints() generates "n" pseudo-random points lying on a sphere of "r" radius
function randomSpherePoints(n=1, r=1) = [for(i=[1:1:n]) random_sphere_point(r)];
randpoints = randomSpherePoints(9999);
list_plot(randpoints,0.01);
changing the number of randomSpherePoints() from 9999 to 10000 makes it break.
"WARNING: Bad range parameter in for statement: too many elements"
I think the 10,000 limit is a reasonable limit to have as a default - an
advanced preference option is a good idea. I'm just beginning to learn
OpenSCAD scripting as it is, definitely not an advanced enough programmer
to alter the source of the program itself in order to add that feature
though. Hopefully it would be a 1-2 liner change somewhere for the
maintainers and script authors can simply add a setting in the script like
$fn to bypass the limit. If it is set as an environment variable then
anyone who writes a decent library for handling large data-sets would have
to make sure users of the library change their OpenSCAD settings from the
default which would result in a lot of head-scratching when people don't
read the notes.
I noticed under Edit > Preferences > Advanced > OpenCSG
There is an option for "turn off rendering at <x> elements". Mine was set
to 10,000 so this may be the source of the error and there is already an
option to up the limit. I upped the value to 100,000, flushed the cache,
and exited/re-opened the program, re-executed the script and the error is
still produced. So this may either be an issue with the render setting
updating, or this is an execution limit that is hard-coded relating to
for() loops and not related to OpenCSG rendering on the screen.
On Fri, Feb 24, 2017 at 1:51 PM, OzAtMichael oz.at.michael@gmail.com
wrote:
Hi David,
You are registered without the ‘+…’, that was after sending the message
below. So I’m replying to get it on the list. (I also Bc’d you in case)
As I mentioned, I think the community would be happy to extend the limit,
as it was somewhat arbitrary.
Let the debate begin, how big is big enough, or maybe make it an advanced
preference, just like the cache size/render limits?
Reply to this (discuss version) to see if it’s working.
Michael
From: David C
Sent: Saturday, 25 February 2017 4:32 AM
To: discuss@lists.openscad.org
Subject: limit to number of elements rendered in a single operation
I was creating some test code for a library I'm writing for OpenSCAD, and
ran into an interesting limitation. When I attempted to render a list of 3D
points as cubes, if the list was >=10,000 elements in size, OpenSCAD throws
an error. If I created two separate lists of points, each <10,000, and
rendered the lists in two separate operations, OpenSCAD doesn't throw an
error and draws the result just fine.
I can't seem to find any documentation as to why this limit exists, or if
it is just a hard-coded sanity check against someone trying to render
something with too many elements. Given there is a work-around of just
splitting up the job, I could write a function that checks the size of the
list I'm about to generate, and split it up if it is too big, but this
complicates things with referencing subset groups in the list if the
elements are spread across multiple list variables.
The following code works, and will render correctly. Change
randomSpherePoints(9999) to randomSpherePoints(10000) and an error will
happen.
// plot a set 3D of points using cubes of adjustable side-length
module list_plot(points,cube_size=0.01){
for(i = [0:1:len(points)-1]) {translate(points[i]) cube(cube_size);}
}
// Spherical (r,theta,phi) to Cartesian (x,y,z) coordinate transformation
// source: Mathematical Methods for Scientists and Engineers - Donald A.
McQuarrie
// x = r*cos(phi)*sin(theta)
// y = r*sin(phi)*sin(theta)
// z = r*cos(theta)
//
// 0 <= r < infinity
// 0 <= theta <= Pi (180 degrees)
// 0 <= phi <= 2*Pi (360 degrees)
// *_sphere_degrees functions take angle arguments in degrees
function x_sphere_degrees(r=1,theta=0,phi=0) = r*cos(phi)*sin(theta);
function y_sphere_degrees(r=1,theta=0,phi=0) = r*sin(phi)*sin(theta);
function z_sphere_degrees(r=1,theta=0) = r*cos(theta);
function xyz_from_sphere(r=1,theta=0,phi=0) =
[x_sphere_degrees(r,theta,phi), y_sphere_degrees(r,theta,phi),
z_sphere_degrees(r,theta)];
// random_sphere_point() generates a pseudo-random point lying on a sphere
of non-random radius "r"
function random_sphere_point(r=1) = xyz_from_sphere(r,theta=rands(
0,180,1)[0],phi=rands(0,360,1)[0]);
// randomSpherePoints() generates "n" pseudo-random points lying on a
sphere of "r" radius
function randomSpherePoints(n=1, r=1) = [for(i=[1:1:n])
random_sphere_point(r)];
randpoints = randomSpherePoints(9999);
list_plot(randpoints,0.01);
changing the number of randomSpherePoints() from 9999 to 10000 makes it
break.
"WARNING: Bad range parameter in for statement: too many elements"
davidconeff wrote
I noticed under Edit > Preferences > Advanced > OpenCSG
There is an option for "turn off rendering at
<x>
elements". Mine was set
to 10,000 so this may be the source of the error and there is already an
option to up the limit. I upped the value to 100,000, flushed the cache,
and exited/re-opened the program, re-executed the script and the error is
still produced. So this may either be an issue with the render setting
updating, or this is an execution limit that is hard-coded relating to
for() loops and not related to OpenCSG rendering on the screen.
That's a separate setting.
p.s. posts are working now, drop the Bc to me next time.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/FW-limit-to-number-of-elements-rendered-in-a-single-operation-tp20555p20557.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
It is a limit to any iteration with for. For instance, the code bellow
generates the same message:
for(i=[0:9999]) ;
@ David. This limit is arbitrary and restricted to for-range. For
instance, the code bellow generates an error due to just the second for:
a = [for(i=[0:999],j=[0:19]) i];
b = [0:30000];
for(x=a);
for(x=b);
The first for is a scanning of a list, the second a scanning of a range.
The range itself does not generate an error message (comment the second for to
confirm).
So, your module should not generate the error if coded as:
// plot a set 3D of points using cubes of adjustable side-length
module list_plot(points,cube_size=0.01){
for(p=points) {translate(p) cube(cube_size);}
}
2017-02-24 19:41 GMT-03:00 Ronaldo Persiano rcmpersiano@gmail.com:
It is a limit to any iteration with for. For instance, the code bellow
generates the same message:
for(i=[0:9999]) ;