Running exportToSvg yields error

Help
1

We are trying to convert our 3D scene into an SVG, but looks like there is a memory issue? The scene has a lot of models in it.

Due to TechSoft3D not supporting DWG/DXF write access, we are trying to create our own DXF by first creating an SVG of the top down view of the scene and then generating a DXF file from the polylines.

Any help would be appreciated! Thanks :slight_smile:

Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 1892679680, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows increasing the size at runtime, or (3) if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0

image
image1532×641 169 KB

2

Hi Mark,

Based on the error, I’m guessing you’re react and some type of react based module to export to SVG. Is that correct? I have seen this error before in react applications (mostly with PDF, but the error looks close to the ones I’ve seen with PDF). Can you confirm that you are/aren’t using react? I’m going to dig into what the fix was for the PDF export and see if maybe that could help.

3

Hi Robert!

I forgot to clarify, I am using this function from HOOPS Communicator Documentation

We are not using React as far as I am aware. For testing exportToSvg, I simply opened the chrome dev console and did the following and then got the error

hoopsWebViewer.exportToSvg().then(data => {
    console.log(data);
});

Thank you for your help, I really appreciate it!!

4

Hi Mark,

my hunch is that this function simply uses a lot of memory for large models (meaning models with a lot of triangles/edges in this case). Obviously if you have a way to reduce the triangle count that would help (maybe by hiding very small parts or generating a lower-tesselation version of the model). If you do the SVG generation server-side (using headless chrome on the server) you would obviously have a lot more flexibility in that regard.

Guido

5

Hi Mark,

Thanks for clarifying. I’d have to echo Guido here and say that it sounds like you may need to find a way to simplify the scene or try performing the export on the server. If you would like to investigate further, I would suggest logging an issue in our support system so that you can potentially share an example file with us and we can do a deeper analysis. I verified that you already have access to our support system if you would like to go that route.

6

Thanks for the help guys! I am going to see if we can simplify our scene somehow or see if we can run the export on the server. For our use case, we might just end up using the bounding boxes instead if all fails.

@rtadlock What would the example file need to contain for you guys to analyse it?

One thing I noticed is that when the SVG does generate, it seems like it creates A LOT of points for simple polylines. For example the first polyline in the svg is the top and left side, and the second polyline is the bottom and right side:

image
image2110×1042 412 KB

Perhaps that’s part of the problem of using too much memory :stuck_out_tongue:

Thanks again!

7

The underlying algorithm has to do a lot of cutting of lines and faces, especially if there is a lot of overdraw in the geometry but there is probably room for improvement. I agree with @rtadlock, its best to file this through our support system who I think have already heard reports of high memory consumption with SVG generation.

With regard to an example model, I would say any SCS file that blows up the browser when generating an SVG (with a corresponding camera) should suffice.

Guido

1 Like