Skip to main content

M3G: viewport after bindTarget()

6 replies [Last post]
Anonymous

Hello all,

If I interpret the M3G spec correctly, the viewport should after a
call to g3d.bindTarget(image), where image is an Image2D object, be
equal to (0,0)-(image.width,image.height). The specification is kind
of vague but says the following:

"The state of this Graphics3D after calling this method [bindTarget]
will be as follows:

viewport : covering the target clipping rectangle"

and "For Image2D targets, the clipping rectangle comprises all pixels
in the target image."

Yet, on all devices I have tried (including Sun WTK2.5-Beta2), the
viewport is set to (0,0)-(0,0) directly after the call to viewport. So
can someone please explain what is wrong?

--
mvh Björn

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Michael Steliaros

Björn (and Robin),

[...]
> Yes, but M3G operations are not only controlled by the MIDP clip but
> also of the origin.

This is true when the user calls setViewport(). However, as of M3G 1.1, as you point out the spec says:

[...]
> And M3G says that the viewport is "covering the target clipping
> rectangle" after bindTarget(), which suggests to me that
> viewport=clip. But it is hard to tell, "covering" is a vague word. :)

After bindTarget() the viewport will be set to the target clip rectangle (which has not physically moved after the translate()). It may be that the use of "covering" was unfortunate but this was certainly the intent. This is what the RI does.

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Web: www.superscape.com
Terms and conditions for email usage: www.superscape.com/email/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

BJörn Lindqvist

On 8/28/07, Michael Steliaros wrote:
> [...]
> > That is true. Although it seems like the interaction between m3g:s
> > viewports and midp:s clipping rectangles is a little strange. Take
> > this code from a method in a Canvas subclass for example:
> >
> > public void paint(Graphics g)
> > {
> > g.translate(getWidth() / 2, getHeight() / 2);
> > g3d.bindTarget(g);
> >
> > At this point, drawing operations should be translated by (getWidth()
> > / 2, getHeight()/2). But they aren't, and m3g rendering will cover the
> > whole canvas and not just the bottom left quadrant of it.
>
> Nope, this is not true. translate() does not alter the location of the
> clip rectangle. From the MIDP 2 spec: "Operations on the coordinate
> system, such as translate(), do not modify the clip."
>
> bindTarget() will bind to the un-translated clip but you can always
> setViewport() after bind which _will_ take clip into account.

Yes, but M3G operations are not only controlled by the MIDP clip but
also of the origin.

M3G spec: "The position of the viewport is specified relative to the
origin of the rendering target. For Graphics targets, this is the
origin in effect when calling bindTarget"

MIDP2 spec: "Translates the origin of the graphics context to the
point (x, y) in the current coordinate system. All coordinates used in
subsequent rendering operations on this graphics context will be
relative to this new origin."

So if before bindTarget(), the translation is (width/2,height/2) and
clip is (0,0)-(width,height), then *if* the viewport is
(0,0)-(width,height) after bindTarget(), m3g should draw in the bottom
right quadrant. On the other hand, *if* the viewport is
(-width/2,-height/2)-(width,height), m3g should draw on the whole
screen.

And M3G says that the viewport is "covering the target clipping
rectangle" after bindTarget(), which suggests to me that
viewport=clip. But it is hard to tell, "covering" is a vague word. :)

--
mvh Björn

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Michael Steliaros

[...]
> That is true. Although it seems like the interaction between m3g:s
> viewports and midp:s clipping rectangles is a little strange. Take
> this code from a method in a Canvas subclass for example:
>
> public void paint(Graphics g)
> {
> g.translate(getWidth() / 2, getHeight() / 2);
> g3d.bindTarget(g);
>
> At this point, drawing operations should be translated by (getWidth()
> / 2, getHeight()/2). But they aren't, and m3g rendering will cover the
> whole canvas and not just the bottom left quadrant of it.

Nope, this is not true. translate() does not alter the location of the
clip rectangle. From the MIDP 2 spec: "Operations on the coordinate
system, such as translate(), do not modify the clip."

bindTarget() will bind to the un-translated clip but you can always
setViewport() after bind which _will_ take clip into account.

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Web: www.superscape.com
Terms and conditions for email usage: www.superscape.com/email/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Robin Chaddock

Not according to the javadoc...

Graphics3D#bind(...)

"For Graphics targets, this is the origin in effect when calling bindTarget"

Graphics#translate(...)

"Translates the origin of the graphics context to the point (x, y) in the current coordinate system"

Scratch up another bug in the reference implementation. (or perhaps the reference specification!)

----- Original Message -----
From: "Michael Steliaros"
To:
Sent: Tuesday, August 28, 2007 10:09 AM
Subject: Re: M3G: viewport after bindTarget()

[...]
> That is true. Although it seems like the interaction between m3g:s
> viewports and midp:s clipping rectangles is a little strange. Take
> this code from a method in a Canvas subclass for example:
>
> public void paint(Graphics g)
> {
> g.translate(getWidth() / 2, getHeight() / 2);
> g3d.bindTarget(g);
>
> At this point, drawing operations should be translated by (getWidth()
> / 2, getHeight()/2). But they aren't, and m3g rendering will cover the
> whole canvas and not just the bottom left quadrant of it.

Nope, this is not true. translate() does not alter the location of the
clip rectangle. From the MIDP 2 spec: "Operations on the coordinate
system, such as translate(), do not modify the clip."

bindTarget() will bind to the un-translated clip but you can always
setViewport() after bind which _will_ take clip into account.

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Web: www.superscape.com
Terms and conditions for email usage: www.superscape.com/email/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Claus Höfele

The viewport values returned by
Graphics3D.getViewportX/Y/Width/Height() are wrong on the WTK (2.5.1).
These methods simply return the last values you set with setViewport()
or (0, 0, 0, 0) by default.

However, even though the values say the viewport is 0 by default, the
actual viewport is set to a reasonable size (at least when using
bindTarget(Graphics); I assume this holds true for bindTarget(Image2D)
as well). It's still a good idea to set the viewport manually to avoid
funny clip rects.

Regards,
Claus

--
Mobile 3D Graphics: Learning 3D Graphics with the Java Micro Edition
http://www.claushoefele.com/m3g/

ISBN: 1598632922
Order from Amazon: http://www.amazon.com/gp/product/1598632922
Barnes & Noble:
http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=97815986...

On 8/27/07, BJörn Lindqvist wrote:
> Hello all,
>
> If I interpret the M3G spec correctly, the viewport should after a
> call to g3d.bindTarget(image), where image is an Image2D object, be
> equal to (0,0)-(image.width,image.height). The specification is kind
> of vague but says the following:
>
> "The state of this Graphics3D after calling this method [bindTarget]
> will be as follows:
>
> viewport : covering the target clipping rectangle"
>
> and "For Image2D targets, the clipping rectangle comprises all pixels
> in the target image."
>
> Yet, on all devices I have tried (including Sun WTK2.5-Beta2), the
> viewport is set to (0,0)-(0,0) directly after the call to viewport. So
> can someone please explain what is wrong?
>
> --
> mvh Björn
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

BJörn Lindqvist

On 8/27/07, Claus Höfele wrote:
> However, even though the values say the viewport is 0 by default, the
> actual viewport is set to a reasonable size (at least when using
> bindTarget(Graphics); I assume this holds true for bindTarget(Image2D)
> as well). It's still a good idea to set the viewport manually to avoid
> funny clip rects.

That is true. Although it seems like the interaction between m3g:s
viewports and midp:s clipping rectangles is a little strange. Take
this code from a method in a Canvas subclass for example:

public void paint(Graphics g)
{
g.translate(getWidth() / 2, getHeight() / 2);
g3d.bindTarget(g);

At this point, drawing operations should be translated by (getWidth()
/ 2, getHeight()/2). But they aren't, and m3g rendering will cover the
whole canvas and not just the bottom left quadrant of it.

--
mvh Björn

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".