tim@resmel.bhp.com.au (Tim Monks) (06/04/91)
What is the fastest way of mapping (x,y,z) (world coords) to (sx,sy)
(screen coords) on a SG?
I know about :
i. Getting the viewing matrix from the pipeline, and inverting this
matrix on the CPU (and various speedups on the same theme,
to make the inversion faster). I don't like the idea of making the
CPU do a job the pipeline should be doing.
ii. Going into feedback mode, and getting results back from pipeline.
Chapter 17 (GL programming guide) says this is a no-no to be avoided.
Are there any better options ?
Thanks in advance,
Tim.
--
Dr Tim Monks
Image Processing & Data Analysis Group | (direct) (+61-3)566-7448
BHP Research - Melbourne Laboratories | (switch) (+61-3)560-7066
245 Wellington Rd, Mulgrave, 3170, | (fax) (+61-3)561-6709
AUSTRALIA | (internet) tim@resmel.bhp.com.autim@merlin.resmel.bhp.com.au (Tim Monks,,) (06/04/91)
To unask the question: I want to draw an object of fixed screen dimensions at (x,y,z) in world coodinates. I can't see how to use matrix ops. to do this. -- Dr Tim Monks Image Processing & Data Analysis Group | (direct) (+61-3)566-7448 BHP Research - Melbourne Laboratories | (switch) (+61-3)560-7066 245 Wellington Rd, Mulgrave, 3170, | (fax) (+61-3)561-6709 AUSTRALIA | (internet) tim@resmel.bhp.com.au
robert@texas.asd.sgi.com (Robert Skinner) (06/04/91)
In article <1991Jun4.032014.18721@resmel.bhp.com.au>, tim@merlin.resmel.bhp.com.au (Tim Monks,,) writes: |> To unask the question: I want to draw an object of fixed |> screen dimensions at (x,y,z) in world coodinates. I can't |> see how to use matrix ops. to do this. |> -- |> Dr Tim Monks |> Image Processing & Data Analysis Group | (direct) (+61-3)566-7448 |> BHP Research - Melbourne Laboratories | (switch) (+61-3)560-7066 |> 245 Wellington Rd, Mulgrave, 3170, | (fax) (+61-3)561-6709 |> AUSTRALIA | (internet) tim@resmel.bhp.com.au why can't you simply replace the viewing matrix with one appropriate to draw your screenspace object, then just draw it? Its not really clear if you have any other requirements you haven't stated, but this seems to be the easy way to draw something in screen space. -- Robert Skinner robert@sgi.com "... friends get free access to private members." - Ira Pohl
kurt@cashew.asd.sgi.com (Kurt Akeley) (06/05/91)
In article <1991Jun4.031535.18607@resmel.bhp.com.au>, tim@resmel.bhp.com.au (Tim Monks) writes: |> What is the fastest way of mapping (x,y,z) (world coords) to (sx,sy) |> (screen coords) on a SG? |> |> I know about : |> i. Getting the viewing matrix from the pipeline, and inverting this |> matrix on the CPU (and various speedups on the same theme, |> to make the inversion faster). I don't like the idea of making the |> CPU do a job the pipeline should be doing. [stuff deleted] If the result of an operation is intended for anything other than the framebuffer, it is NOT the job of the graphics hardware to do it. The best way to transform points is to write code that transforms them on the MIPS processor. If the transform is from world (object) coordinates to screen coordinates, no matrix inversion is required. -- Kurt
slevy@poincare.geom.umn.edu (Stuart Levy) (06/06/91)
In article <1991Jun4.235906.4447@odin.corp.sgi.com> kurt@cashew.asd.sgi.com (Kurt Akeley) writes: >In article <1991Jun4.031535.18607@resmel.bhp.com.au>, tim@resmel.bhp.com.au (Tim Monks) writes: >|> What is the fastest way of mapping (x,y,z) (world coords) to (sx,sy) >|> (screen coords) on a SG? >|> ... > >[stuff deleted] > >If the result of an operation is intended for anything other than the >framebuffer, it is NOT the job of the graphics hardware to do it. The >best way to transform points is to write code that transforms them on >the MIPS processor. > >If the transform is from world (object) coordinates to screen coordinates, >no matrix inversion is required. > >-- Kurt I've wanted to do this too, with yes, destination being the frame buffer. This may not be what Mr. Monks has in mind, but for example what is the easiest way to draw a "wide point" -- a blob of fixed screen-space size, in the location appropriate for a 3-space point, and hidden by surfaces in front of it? GL supports wide lines directly but I don't find anything similar for points. Single-pixel points can be hard to see, especially on video. Stuart Levy, Geometry Center, University of Minnesota slevy@geom.umn.edu
tim@merlin.resmel.bhp.com.au (Tim Monks,,) (06/07/91)
Original question : > What is the fastest way of mapping (x,y,z) (world coords) to (sx,sy) > (screen coords) on a SG? In article <1991Jun4.235906.4447@odin.corp.sgi.com> kurt@cashew.asd.sgi.com (Kurt Akeley) writes: > >If the result of an operation is intended for anything other than the >framebuffer, it is NOT the job of the graphics hardware to do it. The >best way to transform points is to write code that transforms them on >the MIPS processor. > >If the transform is from world (object) coordinates to screen coordinates, >no matrix inversion is required. > The necessary matrix equations are in Appendix C of the old Graphics Library Users Guide version 2.0. (007 1201 020) I cannot find the same info in any of the newer documentation. I have used this successfully. When the destination is the framebuffer there is another way. My particular application was in 2D, so all the transformations are linear. It was only necessary to find the scale factor that mapped 1 pixel in screen space to a dx or dy in world space (these will be different of course). The following code snippet did this : Coord world_x_origin, world_y_origin, /* map screen (0,0) -> world coords */ world_x_pixel, world_y_pixel; /* map screen (1,1) -> world coords */ : : makeobj(w->screen_to_world = genobj() ); reshapeviewport(); ortho2(w->world_xmin, w->world_xmax, w->world_ymin, w->world_ymax); closeobj(); callobj(w->screen_to_world); /* find mapping of screen coords -> world coords */ mapw2(w->screen_to_world,(Screencoord)(0), (Screencoord)(0), &world_x_origin, &world_y_origin); mapw2(w->screen_to_world,(Screencoord)(1), (Screencoord)(1), &world_x_pixel, &world_y_pixel); w->x_pixel_to_dx = (world_x_pixel - world_x_origin); w->y_pixel_to_dy = (world_y_pixel - world_y_origin); : : From article <1991Jun6.054818.29804@cs.umn.edu>, by slevy@poincare.geom.umn.edu (Stuart Levy): > I've wanted to do this too, with yes, destination being the frame buffer. > This may not be what Mr. Monks has in mind, but for example what is > the easiest way to draw a "wide point" -- a blob of fixed screen-space > size, in the location appropriate for a 3-space point, and hidden by > surfaces in front of it? GL supports wide lines directly but I don't find > anything similar for points. Single-pixel points can be hard to see, > especially on video. > Has anyone got a good way of making a wide-point in 3D, as an extension of the code above would not work since the scaling is position dependent? -- Dr Tim Monks Image Processing & Data Analysis Group | (direct) (+61-3)566-7448 BHP Research - Melbourne Laboratories | (switch) (+61-3)560-7066 245 Wellington Rd, Mulgrave, 3170, | (fax) (+61-3)561-6709 AUSTRALIA | (internet) tim@resmel.bhp.com.au
kurt@cashew.asd.sgi.com (Kurt Akeley) (06/12/91)
In article <1991Jun6.054818.29804@cs.umn.edu>, slevy@poincare.geom.umn.edu (Stuart Levy) writes: [stuff deleted] |> I've wanted to do this too, with yes, destination being the frame buffer. |> This may not be what Mr. Monks has in mind, but for example what is |> the easiest way to draw a "wide point" -- a blob of fixed screen-space |> size, in the location appropriate for a 3-space point, and hidden by |> surfaces in front of it? GL supports wide lines directly but I don't find |> anything similar for points. Single-pixel points can be hard to see, |> especially on video. The upcoming 4.0 release supports points of arbitrary size on many platforms. Definitely GT, GTX, and VGX. Not sure about Personal Iris products. -- Kurt