yang686526

sat data units question
sat data units question
the attached dwg file contains a 3dsolid which is, according to autocad, approximately 4 inches x 4 inches square. when i output the .sat file from autocad, i get an sat file which has the same dimensions. when i use dwgdirect and either 1) extract the sat data using a function such as odgetsatfromproxy() or 2) use odamfcapp to view the file's data, the sat data is approximately 4 mm x 4 mm square. i can verify this by looking at the sat data. the header of the sat file reports '1' as the "number of millimeters represented by each unit in model".
has anyone seen this problem and is there anything i can do about it to see that the correct units get put in the sat file? i'm using release 1.13.02.
thanks in advance,
pete rimkus
attached files
hi,
measurement database variable can help you with drawing units (0 inch\1 mm).
odgetsatfromproxy() or mfcapp return internal sat stored in solid. i checked that 3dsolid in your file has next header
1 9.9999999999999995e-007 1e-010 .
if you call acisout command, autocad change header to
25.399999999999999 9.9999999999999995e-007 1e-010
and store in sat. also i saw that if i call saveas, autocad change internal sat header to 25.4, but acisin command ignore this fields there are no differences between drawing of two equal sat file with 1 and 25.4 in header. it will 4x4 inch or 4x4 mm in metric system.
odgetsatfromproxy() or mfcapp doesn't apply 25.4 in imperial drawing
i am not sure that it is bug, it is autocad acisout command extension possibly.
you cannot get/change 1 to 25.4 with 1.13 toolkit, only by parsing the sat string.
alexander,
thanks for the response. to me this seems odd, but it looks like i will have to modify the 1st line of the sat string myself.
i will post my results.
thanks again,
pete rimkus
it looks do-able for solids saved as proxies, since with odgetsatfromproxy() i have access to the sat file character data. it's not easy, but it's possible.
i don't see a similar way to handle this for 3dsolids. i guess my workaround would be to let oddb3dsolid::acisout() write out the (potentially) incorrect units and i would have to edit the .sat file after this.
apparently there is really not a good way of handling this, and i would consider it a bug in dwgdirect.
you can edit it in memory for 3dsolid
odstreambufptr pout = odmemorystream::createnew();
passurf->acisout(pout, kaftypeascii|kaftypeindexed|kafverany);
pout->rewind();
and save it to file after
odwrfilebuf infile(" *** ");
pout.copydatato(infile, 0, end);
we are about to 1.13.5. i have added units functionality to oddbbody::acisout and to modelergeometry interface.
ok - let's see how that works. i'm looking forward to trying it. thanks
i downloaded 1.13.05 from the ftp site and i see that setmmperunit() and getmmperunit() have been added to odmodelergeometry. can i get a brief description of these to see if they solve my sat file 'units' problem?
thanks in advance,
pete
setmmperunit used in
odresult odmodelergeometrycreator::createsat(const oddbentityptrarray &in, ...
and in
static odresult oddbbody::acisout
units will be applied automaticaly if &in has dbr objects.
also you can use code like
code:
if (pdbforunits)
{
oddb::measurementvalue units = pdbforunits->getmeasurement();
if (units == oddb::kenglish)
{
pout->setmmperunit(1.); //pout is odmodelergeometryptr
}
else // if (units == oddb::kmetric)
{
pout->setmmperunit(25.4);
}
alex,
that worked! i found i needed to convert 3dsolids, bodies, and regions to modelergeometry, but that was no big deal to do.
one change i had to make was to flip-flop the scale factors from what you had, as follows...
if (units == oddb::kenglish)
{
pout->setmmperunit(25.4);
}
else // if (units == oddb::kmetric)
{
pout->setmmperunit(1.0);
}
thanks again,
pete
thank you for your membership

how do we set the mm per unit when using
odmodelergeometrycreator::createsat(
const oddbentityptrarray &entities,
odstreambuf* pstreambuf,
aftypever typever,
bool standardsaveflag = true)
odmodelergeometry has a setmmperunit() function which specified the scale. i am not sure how to specify the scale using the function above. is it absolutely necessary to convert the entities to modeler geometry in order to specify scale?
deelip menezes
==========

hello,
createsat method uses pout->setmmperunit call to apply units selected in the database (like in code below). you also can scale the modeler geometry retuned from createsat.
btw : oddbentity has method transformby.

i must be understanding this wrong.
i am refferring to createsat() which uses oddbentityptrarray, not odarray<odmodelergeometryptr>
i have a bunch of oddbentity objects and want to use the createsat() functon, without having to convert them to odmodelergeometry. the createsat() function sets the mm per unit to -1 in the output sat file, which is a problem.
i can scale the individual oddbentity objects using transformby() but that is not the issue. even if i scale the objects, the output sat file will still have a mm per unit of -1.
my question is how do i set mm per unit for the oddbentityptrarray version of createsat()
deelip menezes
==========

it should work automaticaly, if input array containes database resident enitities (it willn't work if all entities are nondbr.). createsat(const oddbentityptrarray has next code :
oddbdatabase *pdbforunits = 0;
...
if (!pdbforunits && (*pentity)->isdbro())
pdbforunits = (*pentity)->database();
....
if (pdbforunits)
{
oddb::measurementvalue units = pdbforunits->getmeasurement();
if (units == oddb::kenglish)
{
poutfile->setmmperunit(1.);
}
else // if (units == oddb::kmetric)
{
poutfile->setmmperunit(25.399999999999999);
}
}
...
poutfile->out(pstreamout, typever, bstandardsaveflag);