catching up on some past issues.
Kevin Rushforth wrote:
> >OK, bitch time :) Why is it that Java3D always seems to want to do
> >things differently to every other Java API?
Firstly appologies. I read back on this and everything really did come
out wrong. I'll blame being highly stressed with my project release
(available for hire, one slightly warn-out programmer. Will work for
peanuts :P ), so I'll try to explain the point a little more clearly
again.
> Because we're not talking about 2D pixel coordinates. The values in
> question are floating-point values specified in a right-handed 3D
> coordinate system (image-plate coordinates) with the origin at the
> lower left corner and Y increasing up, X increasing to the right, and Z
> increasing out of the screen. Whenever Java 3D specifies anything in
> pixel space, we always use the AWT convention of Y-down.
I understand that, but the problem is that you generally are thinking
about how you represent items in standard screen space when you are
projecting things relative to the window. For example, you are rendering
2D stuff in the postSwap() method over the standard screen using the
normal conventions, but you need to flick the thinking around to working
out how to move the projections relative to the screen when trying to
get things to match. Now granted, this is not something that a
"beginner" J3D programmer would be doing, but I feel that we've got a
real potential for problems here.
As Jon mentioned, he wants it relative to the window so that the
projection can be moved off center and then other things rendered around
it (for example, using Mixed Mode rendering to put in the other
objects). I'd like to know that I always set my "center of view" to be X
pixels offset from the corner of the window (Canvas3D). This allows me
to be consistent with the UI as the user may resize the Canvas through
resizing the window. Considering a lot of the other problems that exist
at the moment, re-calculating the exact floating point values from pixel
coordinates is going to be a tricky prospect at best. At a minimum I
could see jumping around of the 3D rendering due to the floating point
inaccuracy (Is it possible to do this back projection from pixel to the
camera coordinate system for the relative values? haven't checked)
I'm not sure that the proposed solution will acheive the desired effect
simply because you are not dealing with things in the user space and
coordinate system (particularly in regard to the code/toolkit that Jon
is working on).
--
Justin Couch Author, Java Hacker
Snr Software Engineer [EMAIL PROTECTED]
ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------
===========================================================================
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".
