Skip to main content

SAT-File (*.sat)

9 replies [Last post]
Anonymous

Hi!
I want to save the java3d-Drawing as SAT-File (*.sat). Does anybody know how can I do it?
Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Matthew Hilliard

Hey. I'm reverse-engineering that format right now (nasty, nasty
intcurves) as you read this, but I'm reading the SAT data and approximating
it in j3d rather than vice versa.

There next to no documentation for it in the public domain since ACIS/SAT
is a proprietary format owned by Spatial Corp, whom I found to be very
accommodating when it comes to selling you their native CAD libraries and
supporting them, but not so much when it comes to dealing with files
generated by/for those libraries and not using said libraries.
(more info at http://www.spatial.com).

You'll have a lot of bloat porting ANY "standard" geometry data to b-rep
data (such as SAT), but the good news is you'll only need to use a very
small subset of SAT/ACIS to export it.

I found the following link useful is describing the file composition overall:
http://astronomy.swin.edu.au/~pbourke/geomformats/sat/sat.pdf

And the only breakdown of SAT variable meanings I could find was ABSOLUTELY
NONE.
I created one myself and my employer doesn't see my project doing what you
need, so I'll share the outcome of my research trials and errors with you
(the tip of the iceberg used to export geometry is as follows):

BODY: every 3d object has one--a SAT file may contain more than one,
usually all at the beginning of the file
{null} (reserved for entity)
*LUMP
{null} no clue at all
{null} no clue at all

LUMP: not really necessary from a geometry perspective, but a
requirement for SAT, so run with it
{null} (reserved for entity)
{null} no clue at all
*SHELL Primary shell
*PARENT (should be body)

SHELL: this is the composite hull of your lump.
{null} (reserved for entity)
{null} possibly sub-shell (invisible geometry)?
{null} possibly sub-shell (invisible geometry)?
*FACE first face in shell boundary
{null} no clue at all
*PARENT (should be lump)

FACE: this is the equivalent of a face in geometry
{null} (reserved for entity)
*FACE next face in parent shell
*LOOP face boundary across a surface
*PARENT (should be shell, perhaps another face?)
{null} no clue at all
*SURFACE plane-surface provides where our polys will lay
*[forward] assume a forward facing loop (clockwise?)
*[single] single / double sidedness

LOOP: face boundary. it will be a collection of coedges. a triangle
loop will be 3 elements long, a quad is 4, etc.
{null} (reserved for entity)
*LOOP Next loop bounding surface
*COEDGE First coedge child
*PARENT (should be face)

COEDGE: like an edge, but with a reference to itself on another face as
well as references to the previous and next coedge on a face's bounding loop
{null} (reserved for entity)
*COEDGE Next in loop
*COEDGE Prev in loop
*COEDGE Shared coedge in separate loop (will be revered if forward and
vice-versa)
*EDGE edge component with geometry
[forward] direction of edge as coedge?
*PARENT (should be loop)
no clue at all

EDGE: an edge just like in geometry
{null} (reserved for entity)
*VERTEX abstract beginning of curve geometry
*VERTEX abstract end of curve geometry
*PARENT (should be coedge)
*CURVE edge data (line segemnt, NURB, ellipse or some worse crap)
[forward] direction applied to the curve type

VERTEX: a vertex just like in geometry
{null} (reserved for entity)
*PARENT (should be edge)
*POINT N dimensions of coodrinates

POINT: actual coordinates for a vertex
{null} (reserved for entity)
X position in space
Y position in space
Z position in space

straight-curve : simplest curve type.
{null} (reserved for entity)
X start this should correspond to a point
Y start this should correspond to a point
Z start this should correspond to a point
X vector X component of unit vector of curve direction
Y vector Y component of unit vector of curve direction
Z vector Z component of unit vector of curve direction
[I] [I] interval along U space for this curve to exist (should be I - I
for straights)

plane-surface: simplest surface type
{null} (reserved for entity)
X point at "center" of the plane
Y point at "center" of the plane
Z point at "center" of the plane
X vector normal of the plane (also portion of plane equation)
Y vector normal of the plane (also portion of plane equation)
Z vector normal of the plane (also portion of plane equation)
I vector direction of V for the plane in UV space
J vector direction of V for the plane in UV space
K vector direction of V for the plane in UV space
[forward_v]
[I] [I] interval along the U space for this curve to exist
[I] [I] interval along the V space for this curve to exist

* indicates an entity reference by line number starting at $1 (first BODY),
and AFTER the three line header.
{null} is a dummy reference: $-1
[] indicates a literal string value which works
anything else is open to some intelligent interpretation.

You'll have to do some calculations like creating an arbitrary V-axis for
your planes, or the representative vector for an edge and figuring which
coedges and edges are forward/reversed and what the line offset of your
references are (it helps to make a big "SAT" data structure and run through
that once its built).

Any questions or comments, please let me know.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Anonymous

Thank you very much for the information

Anonymous

Hi
Do you have any sat-file? If you do can you sent it to me please? I need an example but I can’t find it in the internet. :-)

Matthew Hilliard

Sure.

Here is a "simple" box.

There is 1 body, 1 lump, 1 shell, 6 faces, 6 loops, 6 plane-surfaces, 8
vertices, 8 points, 24 coedges, 12 edges and 12 straight-curves, which is
how it should be for a box if you understand the relationships between the
SAT entities. (Plus you can get a feeling for what I meant by bloat!)

You can map out visually what the box should look like from the 8 point
entries and nothing else.

You should also ignore the lines that begin with "color-adesk-attrib" since
this is an attribute set by autodesk software which will only work when
read by autodesk software. You'll also notice that a number of variables I
labelled as null / "reserved for entity" refer to (index) these also. They
serve the purpose of assigning autodesk-specific data (in this case indices
into a colour table) and are valid sat entries, but are useless for
anything other than autocad. My choices here were to leave them in the
example or re-index everything if I removed them, so I opted to leave them in.

In this example, and MOST sat files with a single body--body is index 0,
lump is index 1, shell is index 2 and the first face is index 3. This
means the first 6 lines (3 for header and 3 for lump, body and shell) in
most SAT files can be pretty much hardwired, if you don't want to generate
them dynamically.

Keep an eye on wrapping in this example, as most web browsers and email
clients will wrap lines that should not get wrapped in a SAT file (watch
for the # at the end of each line, as specified in the SAT document).

One thing I found peculiar in this example is 5 of the 6 faces are
specified "reversed," for no good reason. I don't know if the 5 or the 1
is the misfit, but there it is.
You can obviously do them all forward or reversed or mix them up them if
you like, just watch the normals and direction of traversal for the edges.

If you search for "acis" and "coedge" in google or teoma, you'll be
presented with a whole swarm of example files more interesting than this:

400 103 1 0
7 Unknown 13 ACIS 4.0.2 NT 24 Tue Oct 26 17:08:19 2004
-1 9.9999999999999995e-007 1e-010
body $-1 $1 $-1 $-1 #
lump $-1 $-1 $2 $0 #
shell $-1 $-1 $-1 $3 $-1 $1 #
face $4 $5 $6 $2 $-1 $7 forward single #
color-adesk-attrib $-1 $-1 $-1 $3 256 #
face $8 $9 $10 $2 $-1 $11 reversed single #
loop $-1 $-1 $12 $3 #
plane-surface $-1 3.0382861861344281 2.5050715972949487 5.8785755921539007
0 0 1 1 0 0 forward_v I I I I #
color-adesk-attrib $-1 $-1 $-1 $5 256 #
face $13 $14 $15 $2 $-1 $16 reversed single #
loop $-1 $-1 $17 $5 #
plane-surface $-1 3.0382861861344281 2.5050715972949487 0 0 0 1 1 0 0
forward_v I I I I #
coedge $-1 $18 $19 $20 $21 forward $6 $-1 #
color-adesk-attrib $-1 $-1 $-1 $9 256 #
face $22 $23 $24 $2 $-1 $25 reversed single #
loop $-1 $-1 $26 $9 #
plane-surface $-1 3.0382861861344281 0 2.9392877960769503 0 1 0 0 0 1
forward_v I I I I #
coedge $-1 $27 $28 $29 $30 forward $10 $-1 #
coedge $-1 $31 $12 $32 $33 forward $6 $-1 #
coedge $-1 $12 $31 $34 $35 forward $6 $-1 #
coedge $-1 $36 $37 $12 $21 reversed $38 $-1 #
edge $39 $40 $41 $20 $42 forward #
color-adesk-attrib $-1 $-1 $-1 $14 256 #
face $43 $44 $45 $2 $-1 $46 reversed single #
loop $-1 $-1 $47 $14 #
plane-surface $-1 0 2.5050715972949487 2.9392877960769503 1 0 0 0 0 -1
forward_v I I I I #
coedge $-1 $48 $34 $49 $50 forward $15 $-1 #
coedge $-1 $51 $17 $48 $52 forward $10 $-1 #
coedge $-1 $17 $51 $53 $54 forward $10 $-1 #
coedge $-1 $37 $36 $17 $30 reversed $38 $-1 #
edge $55 $56 $57 $29 $58 forward #
coedge $-1 $19 $18 $59 $60 forward $6 $-1 #
coedge $-1 $61 $62 $18 $33 reversed $45 $-1 #
edge $63 $41 $64 $32 $65 forward #
coedge $-1 $26 $66 $19 $35 reversed $15 $-1 #
edge $67 $68 $40 $34 $69 forward #
coedge $-1 $29 $20 $66 $70 forward $38 $-1 #
coedge $-1 $20 $29 $61 $71 reversed $38 $-1 #
loop $-1 $-1 $36 $44 #
color-adesk-attrib $-1 $-1 $-1 $21 256 #
vertex $-1 $21 $72 #
vertex $-1 $21 $73 #
straight-curve $-1 6.0765723722688563 2.5050715972949487 5.8785755921539007
0 1 0 I I #
color-adesk-attrib $-1 $-1 $-1 $23 256 #
face $74 $-1 $38 $2 $-1 $75 reversed single #
loop $-1 $-1 $61 $23 #
plane-surface $-1 3.0382861861344281 5.0101431945898973 2.9392877960769503
0 -1 0 0 0 -1 forward_v I I I I #
coedge $-1 $76 $59 $62 $77 forward $24 $-1 #
coedge $-1 $66 $26 $27 $52 reversed $15 $-1 #
coedge $-1 $59 $76 $26 $50 reversed $24 $-1 #
edge $78 $68 $79 $49 $80 forward #
coedge $-1 $28 $27 $76 $81 forward $10 $-1 #
edge $82 $57 $79 $48 $83 forward #
coedge $-1 $62 $61 $28 $54 reversed $45 $-1 #
edge $84 $85 $56 $53 $86 forward #
color-adesk-attrib $-1 $-1 $-1 $30 256 #
vertex $-1 $30 $87 #
vertex $-1 $70 $88 #
straight-curve $-1 6.0765723722688563 2.5050715972949487 0 0 -1 0 I I #
coedge $-1 $47 $49 $31 $60 reversed $24 $-1 #
edge $89 $64 $68 $59 $90 forward #
coedge $-1 $53 $32 $37 $71 forward $45 $-1 #
coedge $-1 $32 $53 $47 $77 reversed $45 $-1 #
color-adesk-attrib $-1 $-1 $-1 $33 256 #
vertex $-1 $33 $91 #
straight-curve $-1 3.0382861861344281 5.0101431945898973 5.8785755921539007
-1 0 0 I I #
coedge $-1 $34 $48 $36 $70 reversed $15 $-1 #
color-adesk-attrib $-1 $-1 $-1 $35 256 #
vertex $-1 $60 $92 #
straight-curve $-1 3.0382861861344281 0 5.8785755921539007 1 0 0 I I #
edge $93 $40 $57 $36 $94 forward #
edge $95 $41 $56 $37 $96 forward #
point $-1 6.0765723722688563 0 5.8785755921539007 #
point $-1 6.0765723722688563 5.0101431945898973 5.8785755921539007 #
color-adesk-attrib $-1 $-1 $-1 $44 256 #
plane-surface $-1 6.0765723722688563 2.5050715972949487 2.9392877960769503
-1 0 0 0 0 1 forward_v I I I I #
coedge $-1 $49 $47 $51 $81 reversed $24 $-1 #
edge $97 $64 $85 $62 $98 forward #
color-adesk-attrib $-1 $-1 $-1 $50 256 #
vertex $-1 $81 $99 #
straight-curve $-1 0 0 2.9392877960769503 0 0 -1 I I #
edge $100 $79 $85 $76 $101 forward #
color-adesk-attrib $-1 $-1 $-1 $52 256 #
straight-curve $-1 3.0382861861344281 0 0 -1 0 0 I I #
color-adesk-attrib $-1 $-1 $-1 $54 256 #
vertex $-1 $54 $102 #
straight-curve $-1 3.0382861861344281 5.0101431945898973 0 1 0 0 I I #
point $-1 6.0765723722688563 5.0101431945898973 0 #
point $-1 6.0765723722688563 0 0 #
color-adesk-attrib $-1 $-1 $-1 $60 256 #
straight-curve $-1 0 2.5050715972949487 5.8785755921539007 0 -1 0 I I #
point $-1 0 5.0101431945898973 5.8785755921539007 #
point $-1 0 0 5.8785755921539007 #
color-adesk-attrib $-1 $-1 $-1 $70 256 #
straight-curve $-1 6.0765723722688563 0 2.9392877960769503 0 0 -1 I I #
color-adesk-attrib $-1 $-1 $-1 $71 256 #
straight-curve $-1 6.0765723722688563 5.0101431945898973 2.9392877960769503
0 0 -1 I I #
color-adesk-attrib $-1 $-1 $-1 $77 256 #
straight-curve $-1 0 5.0101431945898973 2.9392877960769503 0 0 -1 I I #
point $-1 0 0 0 #
color-adesk-attrib $-1 $-1 $-1 $81 256 #
straight-curve $-1 0 2.5050715972949487 0 0 1 0 I I #
point $-1 0 5.0101431945898973 0 #

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Anonymous

many thanks :-)
you forgot "End-of-ACIS-data" :-)

Matthew Hilliard

Oh!
The "End-of-ACIS-data" may actually confuse ACIS versions prior to 7.0,
though I haven't rigorously tested it either way. (The demo I gave you and
am currently focusing my efforts on is revision 4--the current revision is
14. Newer revisions can still read older files, so depending on who is
reading your SAT file, you may want to consider that)

Best,
Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Anonymous

Hi Matthew Hilliard!
I have got one question
I can’t understand what does the straight-curve do. I thought the edge lays on the straight-curve but the coordinates of the straight-curve are different from the coordinates of the edge. Can you tell me please for what I need the straight-curve, and how I can define root point and the vector of the straight-curve?
Many Thanks

Matthew Hilliard

Hey Pawlik!

From a SAT-perspective, the loop of curve-types represent the "boundary"
of a surface-type.
In the simplest sense, you start by picturing a surface simply as a
3-dimensional (XYZ) construct which has a well-defined set of rules for
unwrapping into 2d space (UV).
Plane surfaces are the nicest representation of this, as any 2 obtuse
vectors within the surface will unwrap cleanly into the surface's U and V
space, but the file format was written to just as easily describe the
surface from a torus, cylinder, NURBS, etc.
Curves follow a similar paradigm, but in fewer dimensions

This may cause performance difficulties when being read as that while you
save each individual poly into a plane and a small handful of edges (3 or
4), you'll very likely wind up with between 128 and 256 polys representing
it at runtime when read by the acis engine--because the curves could just
as likely be elliptical, one of several spline types, an n-ary polygon
edge, or an arbitrary mix thereof (the loop construct points to a cyclic
chain of coedges, each of which in turn contains a curve).

SAT curve and surface definitions are usually defined with an approximate
center point, and straights are not an exception. Here, the center portion
of the straight-edge can be easily calculated as the average of its two
bounding vertex constructs, and the vector can be easily calculated as the
difference between your ending vertex on the line and the starting vertex
on the line, and then normalized that vector to unit length.
The center doesn't have to be precise (it does have to be a point along the
line intersecting the vertices, so for example you could simply just use
one of the vertices).
The vector can go in either direction, but once you define the edge
direction you may need to reverse it, depending on the direction of the
parent coedges (and remember that because its intended to do breps, each
edge has no fewer than two coedge parents--there is only one parent node
referenced from the straight-edge, but each coedge in the data structure
has its "shared twin" which will refer to the edge as its own) (you can
also reverse the direction of one or both parents, since they represent the
overlap portion of two different surface boundaries), and which way you
traverse the bounding loop. The vertices bound the curve in much the same
way the curve bounds the surface. For a straight curve, using both
bounding vertices and the center/direction pair seems like redundant info
(which in fact they are), but from the context of traversing a loop bounded
by say, an ellipse and a NURBS curve--it makes much more sense.

Despite my incoherent ramblings, I hope that better illustrates what's
happening and how it works.

Matt

At 01:57 PM 1/10/2005, you wrote:
>Hi Matthew Hilliard!
>I have got one question
>I can’t understand what does the straight-curve do. I thought the edge
>lays on the straight-curve but the coordinates of the straight-curve are
>different from the coordinates of the edge. Can you tell me please for
>what I need the straight-curve, and how I can define root point and the
>vector of the straight-curve?
>Many Thanks
>---
>[Message sent by forum member 'Pawlik_Krasnodar' (Pawlik_Krasnodar)]
>
>http://www.javadesktop.org/forums/thread.jspa?messageID=49399샷
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
>For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Anonymous

thank you very much