At 01:32 27.10.00 , you wrote:
>Hi Carl,
>
>Have you actually got this working in practice (I presume so).
Sorry, no. I haven't done an awful lot with Java3D (yet) but I'm good with
reading documentation and interpreting it to make it work, so I tried to
help Mohammed with what I know.
>We were
>going to have multiple locales in our project, but we read all the
>documentation (not much, & a bit cryptic) and we still couldn't get
>HiResCoord to work properly. I think if I recall properly it worked OK for
>small numbers (where you don't really need HiResCoords), but for larger
>values, which we needed to keep our locales sufficiently separated, we
>couldn't get them to work. And if I recall correctly the larger numbers we
>tried which didn't work weren't all that large. You mention something about
>bit twiddling, can you elaborate on this, and why this is necessary? What
>is the difference between a two's-complement fixed-point number and an
>integer?
Well, an Integer in Java *is* a two's complement fixed point number, with
an imagined binary point at the very right, after all the bits. That's why
word 3 and an integer map nicely to one another. The problem is that the
high bit of the integer is the sign bit. If you imagine counting your
integer value up, everything works fine up to 0x7fffffff (2,147,483,647),
but to represent the next larger number, you would need to put 0x80000000
into word 3, which is a negative number when stored in an integer. So to
represent some of those very, very large (positive) numbers will require
effectively putting combinations of positive and negative integers into
those array slots, which is distinctively un-intuitive.
As long as you're within range of a positive 'long' (63 bits), you could (I
think) generate words 2 and 3 like this:
long aaa = <big positive number>;
int word2 = (int) (aaa >>> 32); // extract the high 32 bits into word2
int word3 = (int) (aaa & 0xFFFFFFFFL); // mask the low 32 bits into
word3; this COULD end up negative
This would be an example of the 'bit twiddling' I was talking about; it
gets worse beyond 63 bits because there are no primitive Java data types to
hold integers that big. But then again, I don't think it's likely that you
will be running into such large numbers in any real-world project.
From my knowledge of binary math and practical experience in C and various
assembly languages, this is how it should work. If your J3D models end up
looking cruddy, this COULD be due to bugs or inaccuracies in the actual
implementation (the Library), which I'm sorry to say I have little
experience with. I have never, ever used a HiResCoord and hope I don't ever
have to :)
Hope this helps!
-Carl-
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
