On Sun, 11 May 2008 13:42:14 -0700, "John R. Carroll"
<jcarroll@[EMAIL PROTECTED]
> wrote:
>Cliff wrote:
>> On Sun, 11 May 2008 12:48:48 -0700, "John R. Carroll"
>> <jcarroll@[EMAIL PROTECTED]
> wrote:
>>
>>> Cliff wrote:
>>>> On Sat, 10 May 2008 11:25:19 -0700 (PDT), zxys <paul@[EMAIL PROTECTED]
>
>>>> wrote:
>>>>
>>>>> The negative.. for large 1:1 layouts,.. parasolid has a 1km limit.
>>>>
>>>> Metric software?
>>>
>>> Parasolid has always imposed a limit to the size of the model space
>>> Cliff. It's gotten larger over the years but is still there.
>>
>> Precision (limits) should be in database units but I'd think but
>> they probably chose metric (default for limiting factor units) as 1
>> mm is smaller than 1".
>> Then they can convert back & forth but never exceed their chosen
>> limits in either system.
>> I'd also think that the real limit is a power of 2 (and is
>> based/related to floating point word size, IOW 32 bits).
>> As numbers in computers get larger (or smaller than 1)
>> the distance between any two numbers that can be represented
>> grows larger so more error can creep into calculations & results.
>> There are largest and smallest possible floating point numbers
>> (absolute value other than zero) as well as integers. The next
>> smallest number for floats is quite some "distance" from the
>> largest.
>> All depends on word size (bits) & where they are using the
>> decimal point. But these days we mostly use IEEE 32 bit math
>> (as default) ..
>
>It's something like that but in the end, a cap was imposed for memory
>management and allocation issues.
No matter the absolute size of the number represented by a 32
bit floating point number it has the same number of bits so memory
management and allocation are not issues.
>This also shows up when you im****t tessellated data into anything built
on
>ParaSolid.
Tessellated data would be a huge number of polygons; another matter
entirely.
A 10 X 10 NURBS surface has the same "size" (in bits) in memory &
in a part database no matter how large (or small) the surface is
in square mm.
The problems would be related to trying to produce a BREP
solid when the values of the numbers become larger. They
have to have "mutual" (computed) edges within a tolearnce of
each other & the gaps between sequential discrete numbers
grows larger as the numbers grow larger.
You can increase the tolerance I suppose (bad) or use
more bits in your words (such as 64 bits).
Using UG as an example ... IIRC It's 32 bit with exactly the
same file format on all operating systems. No translation needed
to move a UG part file from UNIX to MS, etc. & have it still work
& be valid (though you'd probably need to run unix2dos on any ASCII
files). (Dos2unix goes the other way.)
>Even the PC based version of UG was a real memory leaker in 1999.
>UG for Unix, OTOH, was another story completely.
No doubt a MS or compiler issue, if so. Same source code for
the most part.
UG was originally written in a whole bunch of languages. Fortran,
Pascal, ... , later a rewrite/****t in C, C++, .... it shows in places if
you
know how & where to look.
--
Cliff
|
