TODO: Fix 3D bugs

*PLEASE KEEP THIS ON TOPIC*

When printing complex objects, Java is running out of memory. The build process needs to be improved to use less memory and replace previous layers with a single object. This is a major bug right now.

How about copying across the prototype model, then clipping it to fit what's been printed? the last layer, or the current layer, can be drawn in in the current way, and then there are only two objects on the progress side, hopefully without actually having to build the progressing object at each layer.

Please excuse me if I'm in error. I know clipping is used to not draw what isn't visible due to obstructions, and isn't it used to not draw what isn't in range? It should be possible, hopefully even reasonably simple, to repurpose it for this.

Minor edit for readability.

Edited 1 time(s). Last edit at 05/16/2007 01:19AM by Sean Roach.

As a workaround, ignoring speed issues, is there a way to tell the Java VM to use more memory and so at least get the build to complete, even if it ends up swapping and so being very slow on machines with insufficient RAM?

Also, can you provide an example that exhibits this behaviour? A link to the relevant .stl file that causes the Java out of memory issue, perhaps?

Lastly, what is the current workaround being used -- a set of Darwin RP parts have been printed on Darwin (right?) so whoever printed them *must* have worked around this issue. How did they do that?

Jonathan

P.S. Wouldn't this sort of bug tracking info be better placed in the Bug Tracker on SourceForge?

a memory workaround would be fine short-term, but we def need to fix the main problem (shouldnt be too hard.)

also, i dont think darwin has printed itself yet. trust me, once that happens, it will be a major event. from there its only a short amount of time until darwin stuff is all over the place =0

ps: yes, we should put this up on sourceforge. infact, i posted a bug about this yesterday.

Status: it appears that the -Xmx option to the Sun Java interpreter can affect this. man java for a few more details.

I ran my Reprap.jar as normal:

java -jar Reprap.jar org.reprap.Main

and loaded the largest .stl in the current set, Corner-bracked.stl and tried to build to "null cartesian" virtual (ie non-existent) Reprap hardware. It dies with lack of VM. So I replicated the bug. OK.

I am now running it with

java -Xxm800M Reprap.jar org.reprap.Main

and it ... swaps like crazy, and runs really really slowly, but it is still running!

This is on an old P4 2.66GHz desktop with 512MB RAM. The Reprap java process seems to need about 1.1GB of RAM, as I interpret top output, so on a Linux box with 2GB or so of RAM, it may well run great. It might even turn out that a smaller value, maybe -Xxm400M or something, might let this run on a 1GB machine.

It's somewhat amusing to see a PC being the bottleneck in extruding :-) :-)

This is *not* to suggest that we should require all Reprappers to acquire PCs with 2GB of RAM (!), but at least this way an initial "can Darwin extrude the RP parts for Darwin" test run could be conducted (by a team member with a more modern PC than I have)! Well, unless my long running Reprap process died unexpectedly in the next few hours, that is :-)

This issue could really use the help of an experienced Java programmer, someone who could both read the code looking for obvious inefficiencies, and maybe also run with profiling output enabled and interpret that to determine what is causing the, ummm, *significant* memory requirements we are seeing!

Incidentally, the estimation functions in the "Tools" menu give me null pointer exceptions, not estimates... is that a known problem?

Jonathan

Hmmm. I left the PC running overnight... after about 16 hours it is still virtually "printing" the corner bracket and has reached a 10.8 layer height!

I've killed it, and am retrying with -Xmx400M to see if that still avoids the out of memory error but uses less swap. Leaving the PC doing nothing but printing a virtual corner bracket for an entire weekend seems like a waste of a PC...

Jonathan