Java representation of .stl file locations

Following some very useful testing with Joost earlier, we now have a single 170Kbyte file Reprap.jar which "is" the Reprap host software and which runs on both Ubuntu Linux and on Windows XP, using the rxtx serial libs, Java3D, and Sun Java 6. This is significant progress towards a far cleaner and easier software install.

However, in the process we found that it uses a lib/reprap-wv.stl file as a resource. How it finds that resource is "interesting". It assumes it is a local file in a directory called lib, either at the current directory level or one level lower.

So there is no way, given that approach, to have the code find and use this resouce within a .jar file.

I started looking at why, and quickly realized the underlying issue: the STLObject library uses type String to represent an STL file location. The norm in Java, as far as I know (and I'm *not* a Java expert!), is to use URLs for resource location, so you can use code like:

-------------------------------------------------------
String myStl = "someplace/somefile.stl";

ClassLoader loader = getClass().getClassLoader();
stlURL = loader.getResource( myStl );
--------------------------------------------------------

And then you will either find it in the .jar, or in the local filesystem.

This could also allow network printing in future, so you might be able to do

reprap --print [www.someplace.com]

and "print" that 3D object from a remote STL file out on the Internet.

QUESTION: Can anyone see a drawback to recoding STLObject to use URL variables for stl file locations, instead of String ?

I'm already part way through attempting such a reimplementation, so I thought I'd ask -- maybe someone already travelled down this road in the past and found problems?? Are there any design documents available for this code?

Thanks,

Jonathan

P.S. Obviously, I could do a quick and dirty hack to look for the reprap-wv.stl file in the .jar and export it to the local filesystem if found, then the code could find it as normal and I'd be doing less work... but it just seems ugly!

Answering my own question...

It works :-)

I've hacked up STLObject to use URLs not Strings and changed the code that uses them appropriately. I've not enhanced the File Open dialog to allow you to specify a remote URL, but that looks quite doable as a nifty enhancement that sort of fell out of trying to get reprap-wv.stl into the .jar file!

I'm getting to the point where I could really use the help of someone to QA these changes (I'm not perfect, my code needs QA like everyone elses!) and commit them into the project repository if no issues are found...

Jonathan

i'd love to check out the latest copy of what you've got going. please just post it in the forums or email it.

also, with this method, would it be possible to use the new call, but still have the STL file in a folder? perhaps something better than lib/, like data/?

is it possible to make a normal .zip file in ant? then we could copy a data directory over to it and then zip it all up.

ZachHoeken Wrote:
-------------------------------------------------------
> i'd love to check out the latest copy of what
> you've got going.
-------------------------------------------------------

Yes, it's amusing, you're happy with the success of a Reprap,jar that is already several days old, and therefore already obsolete :-)

I'd love to check it in so you could do that :-) Paging Adrian...!?

> please just post it in the forums or email it.

OK. I don't like publishing code this way... we have a full blown
svn setup, we *really* should be using it...!

Attached is my current Reprap.jar including the STLObject conversion to URLs... code is somewhat untested, but has at least built one virtual STL file using null cartesian :-)

> also, with this method, would it be possible to
> use the new call, but still have the STL file in a
> folder? perhaps something better than lib/, like
> data/?

You can put it *anywhere*. The default one is in the .jar, but
an end user can override it as needed. Right now my code just looks
for whatever you have as WorkingLocation in your reprap.properties file.
The reprap.properties.dist is in the .jar, but you can extract it, rename it to reprap,properties, and edit it to your heart's content... you can put a full path in there if you need to do that (hmmm, I should probably test that!).

I could check a set of subdirs (as before) if that is wanted... but I'm not sure hard coding a set of subdirs into the code is good design. Especially if you don't document what they are :-) Was the rationale for that design choice documented anywhere?

Why not just let people who need to edit the background also use reprap.properties to point to their nice new modified background?

> is it possible to make a normal .zip file in ant?
> then we could copy a data directory over to it and
> then zip it all up.

It's probably doable, but seems sort of self-defeating... we should put small amounts of necessary initialization data into the .jar anyway. The big set of .STL files for Darwin should IMO stay separate, since they will change at a different rate from the host software, and their release will be managed by a different "Release Lizard" -- right?

My ant setup is under the Reprap subdirectory at the moment... it is intended for building and packaging the Java host code, only. That's what ant is good at. I think higher level "packaging the set of packages" work to bundle other stuff with it should come later, and may use different tools.

We will want:

* The host software (and ancilliary files needed to make running it easy)
* The Java3D libraries
* The rxtx serial libraries
* The .hex firmware files
* The .stl files
* The electronics files (PCB layouts, schematics, BOM parts list)

I seem to have taken responsibility for the first three of these items.

We already seem to have the .hex files (individually, for some reason) and a .zip of the ,stl files, available on SF for download., If the kits end up incuding fully assembled boards, the electronics files are in some sense optional for non-developers. That leaves the host software (we're getting close!), and the two libraries (not worked on yet beyond understanding the install location issues for them in some depth).

Once we have each of these six items in easily installable form, we can look at stuffing them into one massive "just give me all of it *now*" installer, if there is really a market for that.

Jonathan

Here is the result of executing

svn diff

in my Reprap subdirectory.

No huge changes, only about 25 lines of Java code affected so far, plus the 5 to switch to using rxtx libs.

Jonathan

> You can put it *anywhere*. The default one is in
> the .jar, but
> an end user can override it as needed. Right now
> my code just looks
> for whatever you have as WorkingLocation in your
> reprap.properties file.
> The reprap.properties.dist is in the .jar, but you
> can extract it, rename it to reprap,properties,
> and edit it to your heart's content... you can put
> a full path in there if you need to do that (hmmm,
> I should probably test that!).

awesome. i still think we should have stuff that can be user editable live in the filesystem just to make things easier to understand. i dont really know how i would go about 'extracting' the reprap.properties file. the stl isnt nearly as important, but it would be nice to have that easily changeable for those wishing to tweak it. i wasnt suggesting that we add all of the darwin stl files to the data dir, just those that are required to run the software (eg. the background file)

> i still think we should have stuff that can be user editable live in the
> filesystem just to make things easier to understand. i dont really know how i
> would go about 'extracting' the reprap.properties file. the stl isnt nearly as
> important, but it would be nice to have that easily changeable for those wishing
> to tweak it.

Right now, you'd do

jar xf Reprap.jar reprap.properties.dist

to extract it (jar is very like tar). In a bit, you just use the properties dialog and a new reprap.properties file "appears" for you. I suppose I see a .jar as being a "container" for the app, and it therefore should contain everything the app needs to run, once you have the appropriate Java environment. And users shouldn't edit reprap.properties.dist anyway, but if we put it in the filesystem, some people will edit it, rather than creating reprap.properties, so defeating the whole idea of ".dist".

For user support, being able to ask a user to move any reprap.properties* file(s) out of the way and then try again could be a very useful way to ensure the issue they are having is not just a result of their own tweaking... otherwise you'd probably have to go through every single field of the properties dialog and tell them what the defaults are...?

We can do it either way, it's just a difference in approach.

Jonathan

cool. i suppose it is easy enough to change it if we want to do it a different way in the future. thanks for the help!

Can anyone help me in writing the java code to generate the stl file?
Please reply me soon.....

how to divide the vertices into triangles using java code. please help me?

public class Cruciform {
public static void main(String[] args) {
// TODO code application logic here
Scanner obj = new Scanner(System.in);
float l,b,h;
System.out.println("length");
l= obj.nextFloat();
System.out.println("breadth");
b= obj.nextFloat();
System.out.println("height");
h= obj.nextFloat();
float [][]bottom_vet=new float[][]{
{0,0,0},{l,0,0},{l,b,0},{2*l,b,0},{2*l,2*b,0},{l,2*b,0},{l,3*b,0},
{0,3*b,0},{0,2*b,0},{-l,2*b,0},{-l,b,0},{0,b,0}
};
float [][]upper_vet=new float[][]{
{0,0,h},{l,0,h},{l,b,h},{2*l,b,h},{2*l,2*b,h},{l,2*b,h},{l,3*b,h},
{0,3*b,h},{0,2*b,h},{-l,2*b,h},{-l,b,h},{0,b,h}
};
float tri[][]=new float[24][9];
for(int i=0;i<12;i++)
{

for(int j=0;j<3;j++)
{
tri[j]=bottom_vet[j];
System.out.println(tri[j]);

}
i++;
for(int j=3;j<6;j++)
{
for(int k=0;k<3;k++)
{
tri[j]=bottom_vet[k];
}
}

}

}
}
anyone please find me out the error