Home
Reply
Contributor
robc
Posts: 21

ACIS FILE SIZE

Hi,

 

I have a requirement to 'simplify' an ACIS model such that the simplifed SAT file

models the original to with a tolerance but the actual file size is much smaller.

 

I know this is a bit of 'arm waving' but I am looking for guidance as much as anything.

 

Given that I noticed that the spines and p-curves seemed - very well defined and acounted

for much of the file size :

 

So far I have tried two approaches :

 

One

--------

 

1) I thought that a bigger value of resabs would help - it does but only knocks off

a few % of the file size per order of magnatude - or there abouts

 

2) I tried the 'api_simplify_entity' hoping that this would create reduce the nurbs definitions

but again I didnt see any improvment -(I simply applied this API call to all BODY's with the

various options set ) if that correct ?

 

 

two

------

 

I tried to present the data in a tesselated form, by creating many bobies with single faces, each face

being planar. This seemed to create a file just as big (if not bigger) I guess because of the large number

of topological entities created - lumps, shell, face, edge ....

 

Looking at the file I guess that even if I grouped the faces into a single body (as a tri-strip for example)

the file would still be large.

 

 

summary

--------------

 

So can anybody suggest the best approach ? is it possible to simply reduce the quality/size of

spline data ? or is it better to persist with the tesselated idea ?

 

What I really need is a magic wond that reduces the file size by say 1 or 2 degrees of magnitude !

 

Any help greatfully recieved.

 

I attach a typical SAT files that I would like to reduce ...

 

(The tessellated one illustrates how coarse the model can, but as

you will see it is still a large size)

 

Thanks

 

Rob Cox

Spatial Employee
asdf
Posts: 93

Re: ACIS FILE SIZE

Hi Rob

 

I haven't looked at your sat file yet, but after reading your message there are a few comments I think are relevant.  The SAT format was never intended for storing triangulated data, but if triangulated data is good enough for your application, there are quite a few formats which may work for that: STL (if you don't need surface normals at the vertices), hsf (if you have access to hoops), ...

 

The other immediate suggestion is that if you want to store the full detail of ACIS data in a smaller format use SAB.  Writing the data out in binary form instead of ascii form can save quite a bit of memory.

 

I will have a quick look at your sat file and let you know if I can think of anything else.

 

cheers

 

Eric

Contributor
robc
Posts: 21

Re: ACIS FILE SIZE

Thanks for the reply, but it has to be a SAT file.

 

I have since found that I can omit the 2d edge curves which helps, but would like

to simplify the 3d edges and surfaces if possible

 

Thanks

 

Rob

Spatial Moderator
rbagley
Posts: 120

Re: ACIS FILE SIZE

I'm curious, Rob - why must you use SAT over SAB?  They are functionally equivalent with the exception of being human-readable (or not), and SAB is both smaller and faster on read & write.

Contributor
robc
Posts: 21

Re: ACIS FILE SIZE

I know it is strange, but that is the requirment of down stream system

Spatial Moderator
ybiyani
Posts: 223

Re: ACIS FILE SIZE

Is the downstream operation in your application or another application?
Contributor
robc
Posts: 21

Re: ACIS FILE SIZE

Downstream is a 3rd party (not ours) application.

Contributor
Sarvnaz
Posts: 25

Re: ACIS FILE SIZE

Is this 3rd party application a visualization application? It seems like you are considering tesselated data only. Is this correct? If not, can you explain a little bit about what this third party application is and what it does?