Are you able to attach the scad file and a link to the data set/details of any processing applied (this looks to be NASA/USGS topographic data for Yosemite)?
The error given would typically be linked to an attempt to allocate more memory than is avaliable and will be very difficult to debug without the relevant supporting data.
It may be worth giving the snapshot builds (https://openscad.org/downloads.html#snapshots) a test in the meantime as there have been a lot of changes since the last release.

from openscad.

yosemite_usa_srtm1.txt

can't download the snapshot builds :
OpenSCAD-2024.05.26-x86-64.zipFailed - Network error

thanks n best regards

from openscad.

Download works fine here.

wget https://files.openscad.org/snapshots/OpenSCAD-2024.05.26-x86-64.zip
--2024-05-27 17:45:57--  https://files.openscad.org/snapshots/OpenSCAD-2024.05.26-x86-64.zip
Resolving files.openscad.org (files.openscad.org)... 45.129.182.88
Connecting to files.openscad.org (files.openscad.org)|45.129.182.88|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 55982902 (53M) [application/zip]
Saving to: ‘OpenSCAD-2024.05.26-x86-64.zip’

OpenSCAD-2024.05.26-x86-64.zip 100%[=================================================>]  53,39M  16,1MB/s    in 3,6s    

2024-05-27 17:46:12 (14,9 MB/s) - ‘OpenSCAD-2024.05.26-x86-64.zip’ saved [55982902/55982902]

from openscad.

I was able to preview and render this on snapshot (with manifold)
as no scad was supplied I used minimum viable import surface("yosemite_usa_srtm1.txt");
During render this peaked at 7.5GB of ram in use.
Update: I was also able to repeat this on the release version, peak ram usage was slightly lower with that.
without seeing if there is anything in your scad code to cause an unexpected bloom in memory this appears to be a ram starvation issue with a large dataset.

from openscad.

with the same scad code from above
surface("yosemite_usa_srtm1.txt");

still got same result,
the memory consumption highest reach
during opening the file are around 5 gb, not reach 6 gb

best regards

from openscad.

fun fact :

1 can open the data in *stl file with same source e.g. yosemite_usa_srtm1.stl,

because it's generate from same resources and for this issue,
the source translate into ascii with command :
gdal_translate -of AAIGrid yosemite_usa_srtm1.tif yosemite_usa_srtm1.dat

2 the gdal_translate is not on fault here

because can open for srtm3 file (srtm3 file around 1 mb, because the different in resolution between srtm1 n srtm3 file)

3 for ram starvation

from pic posted before, it's not make sense,
as you can see the ram consumption not even reach 7 gb on my task manager

best regards

from openscad.

The error given indicates that openscad asked the operating system to allocate more memory and it was unable to do so. It is possible that openscad requested an additional 2GB of ram for instance when around 1 was available and that caused the request to be refused. It is highly likely the STL you have generated has fewer points than are generated in the surface function run against the raw data. There are around 2M points in your data list and each of those will end up with multiple triangles coupling each of the edges, This is very ram hungry, if you are able to generate an STL or 3mf directly from your conversion utility and then work with that I would recommend doing so. I do not believe that this is directly a bug in openscad and is instead is an example of running out of allocable memory.

from openscad.

the different withtin stl and dat output is
the dat include base layer, while stl only show top layer of elevation

question
1 how to load *stl file with base layer included, like shown on srtm3 *dat above ?
2 is it possible to set memory allocation during opening openscad ? or just increase my physical ram on current device ?

from openscad.

@Scopeuk were you using Windows to reproduce the issue? I found this issue weird because the peak memory usage of the program is around 4.2GB (on Linux), and from the OP's screenshots there should be sufficient memory to serve the request. And when Windows go out of memory, iirc it will try to compress memory or use swap to serve the allocation request.

from openscad.

from openscad.

I did attempt the reproduction on windows however the machine used has 16 gigs of ram.
Windows would typically go to swap etc, it is possible that the allocation asked for contiguous memory which would could prevent this.

@sugizo

1. there is no direct way to load an STL with the extra volume below, the STL does not contain this information and is just a surface, openscad draws this as such.
2. there is not currently anything to restrict openscads use of ram (other than the cache size). In this case (optimisations to reduce memory usages aside) I would only expect us to generate an error.

It would be interesting to see if command line execution prints the full "what" from the exception. Ultimately we can consider an improvement and/or optimisation to reduce memory usage in this or similar cases.

from openscad.

fixed in development version,
can be opened without error appears,
but
the response takes time
when editing the value
e.g.
edit z value

from openscad.