Zach 'Hoeken' Smith wrote:

> > for the orientation stuff, i'm thinking that its a count of how many
> > times you rotate over that axis (as you currently do when you load an
> > object) we'd have to keep track of that in the software so that when
> > you load a STL, you manipulate it and then can save the setup as a
> > reprap build file.
>
> Rotation about each axis measured in degrees would make for a far more
> readable file format, IMO. Normally we'd only expect to see values of ,
> 90, 180 or 270, but there could be times when other angles between 0
> and
> 360 degrees are useful.
>
>
> heh, you probably could've stopped here. another good suggestion.

We need to be able to store the rigid body transforms of translation and
rotation in their most general and unambiguous form. This essentially
means recording a Java3d transform matrix, I think. Not wonderfully
human-readable, but simple to read, to manipulate, and to output.

> I would also like to see the file format handle URL pointers to STL
> files, rather than always including the files locally; this could allow
> very small metafiles that allow one to print from an online or (local
> network accessible) library or set of libraries, rather than always
> moving copies of (large) STL files around and storing them locally. If
> we expect to one day be creating "integrated" networked RepRaps that
> need no associated host PC, and have no rotating storage, this sort of
> thing becomes necessary, not just nice to have. So instead of
>
>
> another good suggestion. this is a dream we both share =) changing the
> attribute to 'location' or something like that would be a good idea as
> well.
>
> the filetype could probably be optional, as the host software could
> probably figure it out based on extension, although you'd be free to
> specify it yourself.
>
> anyway, heres my revised example html file:
> [bom.reprap.org]

I like that a lot (possibly with the transform bit I mentioned). I'll
carry on modifying the internals of the program (which are obviously
independent of the file format). I particularly like the
filetype="application/sla" bit which allows us to have more sensible 3d
formats than just stl.

So - just to get things clear as I'm dim as usual - we have a zip file
(possible extensions: .rr .rep .rap - how does one go about "reserving"
one of these?) that contains files:

Zach's XML
STL-file1
STL-file2

etc.

Java must have something already in for packing and unpacking these.
Anyone know where I should look?

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

>
> We need to be able to store the rigid body
> transforms of translation and
> rotation in their most general and unambiguous
> form. This essentially
> means recording a Java3d transform matrix, I
> think. Not wonderfully
> human-readable, but simple to read, to manipulate,
> and to output.

i'm not entirely sure what that means, but if you want to give me a sample output of that that information looks like, then i can help modify the XML format.


> So - just to get things clear as I'm dim as usual
> - we have a zip file
> (possible extensions: .rr .rep .rap - how does one
> go about "reserving"
> one of these?) that contains files:

>
> Zach's XML
> STL-file1
> STL-file2
>
> etc.

exactly. you should either choose an extension (as benevolent dictator) or we could do a poll. my suggestion is .rro (RepRap Object)

list of extensions:
[whatis.techtarget.com]

> Java must have something already in for packing
> and unpacking these.
> Anyone know where I should look?

[java.sun.com]

looks promising. open office also uses this stuff, so if we cant figure it out, we could always *borrow* some of their code... open source =)

> i'm not entirely sure what that means, but if you want to give me a sample
> output of that that information looks like, then i can help modify the XML format.

We have to record a 4x4 matrix of doubles:

1.0, 0.0, 0.0, 30.5
0.0, 1.0, 0.0, 7.5
0.0, 0.0, 1.0, 20.0
0.0, 0.0, 0.0, 1.0

For an explanation of what this does, see [java.sun.com]

and (possibly even more frighteningly):

[en.wikipedia.org]

File extensions:

Let's go with .rro. I've e-mailed whatis.techtarget.com to ask them to add it.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

I'm not a 3D expert, but my gut reaction is that the matrix algebra transforms are total overkill in the direction of flexibility, at the expense of human readability/understandability. Anyone doing scaling, never mind shears and non-affine transformations, should *surely* be doing them in their 3D modelling software, not in our .rro files!?

All we need is to be able to rotate the object about any axis, and translate it along X and Y (and *maybe* Z if you're going to also define an ordering of object building and try to print one object on top of another).

So I suggest that we need 3 numbers representing rotation in degrees about each of the 3 axes, and 3 more representing translation along each of the three axes in millimeters. That is six numbers rather than sixteen, and is vastly more "readable" by mere mortals IMO.

Can someone come up with a vaguely plausible example of usage where the extra flexibility of the scaling and shearing etc. that the matrix provides is necessary? Or useful?

Jonathan

I agree that it's not wonderfully readable (though the 1.0s down the
leading diagonal are a bit of a giveaway). But homogeneous coordinates
are ubiquitous and exclusive: every piece of 3D software uses them and
only them for this purpose. We could use a quaternion and a
translation vector instead, and that would remove the superfluous
shearing and scale-change affine transforms, but at the expense of
doing something non-standard. And I don't envisage people editing this
bit of the XML by hand; I think we can use one of these new-fangled
computer thingies for that.

We definitely need the Z translation, incidentally. Putting one thing
on top of another is one of the main points of the exercise.


Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]



_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

> And I don't envisage people editing this
> bit of the XML by hand; I think we can use one
> of these new-fangled computer thingies for that.

In the network world, it is amazing how many times people have said "it doesn't matter if what it looks like on the wire is hard for humans to read, the computers will be the ones interpreting it"... and then (re-)discovered how much of a pain that makes troubleshooting and debugging!

I think that for a while (at least until someone writes the software to do it for us!), we'll be hand-creating .rro files. Later we'll probably be debugging broken ones or misbehaving ones. But OK, at least we're using XML, so the data is human-readable at that level. It's just that in either of these cases, you need to get a calulator out (or some other piece of computational software, GNU Octave maybe) to understand what the transform matrix you just read actually *does* -- since in these circumstances by definition you can't trusting your own software: either it doesn't yet exist, or you're debugging files it very likely created!

I'm definitely OK with using a transform matrix if it's really "the standard", and will hope that there are plenty of 3D afficionados out there who can "read" such matrices decently when needed.

[Aside: What I remember from my (high school!) matrix math is that you use a 3x3 matrix to transform points in 3D space represented as a 3 element vector... so why do we need 4x4 ? Just curious! ]

Jonathan