RepRap: Blog

I'm left to wonder whether this app is going to be another memory pig like AoI seems to be so much of the time. Now that I have four gig of memory Aoi seems to behave fairly well. Back when I only had a gig, though, I could regularly create objects in a session, save them and then find that I could load but not display them again until I removed a lot of the pieces in the object. :-(
 

Does the software need to display/render all the crosshatching? It'd be nice for debugging purposes, but for general use, is it necessary?

How about adding some more rendering views/options?

#1 Displaying the single (mesh?) object (ie: just the solid object itself, not what makes it up)
#2 Displaying the vertical layers of the object (y axis?) with each layer being a solid sheet (stacked)
#3 Displaying the cross hatching on an individual layer (either in debug to check/test each layer visually or as that layer is being extruded)
#4 During production, display the vertical layers of the object that have been made (#2) along with the cross hatching that has been done/to be done (different colors) on the layer that is being done (#3)

I'm not familiar with Java3D (in fact, java is one of the languages I haven't quite gotten around to getting familiar with) but I'm drawing on my past experience with other rendering tools/etc...
 

That's a good idea. You could render the object as a solid up to the penultimate slice, then just render the current slice details as it is built.
 

Is this going to send instructions to the axes as well or is it just driving the virtual printer?

If it's going to drive the real thing, I've just got my extrusion head mounted up firmly over the stage and I'll give it a bash.

I need to sort out some decent connectors (no personal cash at present) hand-roll a bit of 3mm feedstock, and test the heating element but I think I'm just about ready for it.

Vik :v)
 

AoI takes a command line parameter to increase available memory. This is detailed on their site in the FAQ.

Vik :v)
 

Is this being done with Java3D/OpenGL? or some other method with Java3D? A friend of mine (who does java for a living, but not java3d) thinks that Java3D/OpenGL would be comperable to C++/OpenGL

Also, what kind of video card are you using to test? (is it a 3d card? low end? high end?)

Also also, is lighting/textures being used at all? or has that been taken out of the equation? (I don't see any texture or shadows, but the two directions clearly look to be different 'colors' (or at least different shades of the same color) to me...
 

I still haven't had time to look at all the code concerning this but I assume you are running all this off a single generic file type like a .dxf from which to produce the object?

If so then only a few public variables or exposed program vectors (dangles if you would) could pipe out details like which layer is being rendered etc. and people could apply their own image rendering services such as DirectX, POV-RAY, OpenGL, or even GIMP to produce the required image depending on the system and level of performance they have. Then the image could be dumped back into the reprap display window.
Since you're using java it's safe to say everything you've done so far is just about this modular anyways.

Specifying the I/O structure of render details, a file pointer and a handle for returning the rendered pic are the only things that would need to be done. And none of that would impact the design you already have in hand, merely add to it. No promises but I'll really try to look into that particular code this week.

Keep up the good work everybody, Reprap rules!
 

This preview looks the same whether you use the null printer or the real printer. So yes, you can really print this to the real motors.

It takes quite a long time to run on the motors at the moment...