> However I'd like a TRON grid.  In TRON the width of the grid lines doesn't
> narrow with distance from the camera quite as it should.  There is some
> narrowing going on but note in the gif I posted above that the narrow
white
> lines soon fill the entire plane in the distance.  Its this effect that
has
> now been copied in Realsoft 3D and I'm curious if POV-Ray can do it as
well.

An interesting problem. In the below code I've used a function to make the
lines get thicker as they get farther away from the camera. They still
appear thinner in some places, because the angle from the camera to the
plane gets shallower. I also used a function to create the "horizon glow"
effect. It should be fully animatable if you want to change the camera
location (camloc). I'll post an image in p.b.i shortly.

#declare camloc = <0,5,0>;

camera
{
 location camloc
 look_at <5,0,10>
}

#include "functions.inc"

#declare camlocx = camloc.x;
#declare camlocy = camloc.y;
#declare camlocz = camloc.z;

// replace the contents of getThickness with a single number
// (such as .03) to have a uniform line thickness everywhere.
#declare getThickness = function(x,y,z) {
 //.03

 // we want the thickness at <x,y,z> to be proportional
 // to the distance from the camera
 .003 * f_sphere(x - camlocx, y - camlocy, z - camlocz, 0)

 // if the effect is too strong, the above could be
 // combined with a constant number; for instance
 // (the above equation) * .7 + (normal line thickness) * (1 - .7)
}

#declare gridlinefunc = function(x, Thickness) {
 min( x - floor(x), 1 - (x - floor(x)) ) + max(.5 - Thickness, 0)
}
#declare gridfunchelper = function(x,y, Thickness) {
 min(gridlinefunc(x, Thickness), gridlinefunc(y, Thickness))
}
#declare gridfunc = function(x,y,z) {
 gridfunchelper(x, z, getThickness(x,y,z))
}

// returns dot product of angle to camera and <0,0,1>
#declare angleToCamera = function(x,y,z) {
 (camlocy - y) / f_sphere(x - camlocx, y - camlocy, z - camlocz, 0)
}

plane
{
 y, 0

 texture
 {
  pigment
  {
   function {gridfunc(x,y,z)}
   pigment_map {
    [.49 rgb 1] // white line
    [.51
     // blue turning to green in the distance
     function {angleToCamera(x,y,z)}
     color_map {
      [0 rgb <.3,.9,1>] // horizon color
      [1 rgb <.3,.6,1>*.85] // nearby color
     }
     // use poly_wave numbers closer to 0 to favor
     // the nearby color, closer to 1 or higher to
     // favor the horizon color
     poly_wave .3
    ]
   }
  }

  finish {ambient 1 diffuse 0}
 }
}


 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Am Sat, 08 Jul 2006 17:06:25 -0400 schrieb Carl:


> I guess I should have been more specific.  I can make a nice grid.  Here is
> what I'm using at the moment.
 
I dont't quite get why you're using x and z in squares and I would use
abs(mod(x,1)) instead of abs(x)-int(abs(x)) but these are subtleties.
Actually I gave up to understand the function, sorry ;-).
 
> However I'd like a TRON grid.  In TRON the width of the grid lines doesn't
> narrow with distance from the camera quite as it should.  There is some
> narrowing going on but note in the gif I posted above that the narrow white
> lines soon fill the entire plane in the distance.  Its this effect that has
> now been copied in Realsoft 3D and I'm curious if POV-Ray can do it as well.

Ok, I missunderstood you then.
Indeed this is very interesting and looks better than the grid narrowing
which is prone for artifacts in raytracing.
I guess the best aproach would be the "Angle of incidence" pattern from
megapov but a cylindrical map that fades out with the distance should
do it as well (I don't have megapov installed at the moment anyway).

Here's a snippet from the texture which is used in the image in p.b.images.
The camera position has to be declared before. It is used to translate
the mask right under the camera.

#declare grid_fade_disc_rad  = 40.0;
#declare grid_fade_disc_pos  = <cam_pos.x, 0, cam_pos.z>;

#declare T_Actual_Grid =
  texture { T_Grid finish {ambient 0.1}}
  texture {
    pigment {
      cylindrical 
      color_map {
        [0.0 rgb  grid_line_col]
        [1.0 rgbt 1.0]
      }
      scale grid_fade_disc_rad
      translate grid_fade_disc_pos
    }
    finish {ambient 0.1}
  }

Another idea is to alter grid_fade_disc_rad with the height of
the camera above the plane.

Regards,
Sebastian

P.S.: There's a demo scene in p.text.scene-files

Post a reply to this message

"Carl" <car### [at] semisouthcom> wrote:
> I'd like to try and copy the game grid effect as seen in the movie TRON.
> Check out this example for those who aren't familiar with it.
>
> http://www.wwwmwww.com/Matt/Animation1.gif
>
> Here is one of my current POV-Ray renders...
>
> http://www.wwwmwww.com/Matt/hover2.png
>
> However reciently I've been pointed to this work done in Realsoft 3D
>
> http://www.matthias-kappenberg.de/index.php?id=165
>
> Can anyone here tell how he pulled off this effect?  And better yet can it
> be copied in POV-Ray?
>
> Thanks,
> Carl

Have a look at this code I threw together.  The function generates a grid
with a given spacing.  The gridline width varies from the specified GW at a
distance 0 from the camera (or CL) to the full grid spacing at infinity.
The widening is an exponential function and the WF term defines how quickly
the gridlines thicken.


//start
global_settings {assumed_gamma 1.0}

#declare CL=<5,10,-5>;

camera {
  location  CL
  look_at   <0.0,6,  0.0>
}


#declare GS=10;//grid spacing
#declare GW=1;//gridline width (at distance=0), (gridline width = GS at
infinity)
#declare WF=1/500;//gridline widening function (<0 widens)

#declare Cx=CL.x;
#declare Cy=CL.y;
#declare Cz=CL.z;

#declare GLW=function(Dst){GW+(GS-GW)*(1-pow(1/exp(Dst),WF))}//widening
function =GW at 0, =GS at infinity
#declare
G1=function(Dir,Dst){select(GLW(Dst)-abs((GS/2-abs(mod(Dir,GS)))*2),0,1)}//gridline
function
#declare dist=function (x,y,z){sqrt(pow(Cx-x,2)+pow(Cy-y,2)+pow(Cz-z,2))}
//distance from CL

plane {
  y, -1
  pigment { function{max(G1(x,dist(x,y,z)),G1(z,dist(x,y,z)))} }
  finish{ambient 1}
}
//end

-tgq

Post a reply to this message

"Carl" <car### [at] semisouthcom> wrote:
> I'd like to try and copy the game grid effect as seen in the movie TRON.
> Check out this example for those who aren't familiar with it.
>
> http://www.wwwmwww.com/Matt/Animation1.gif
>
> Here is one of my current POV-Ray renders...
>
> http://www.wwwmwww.com/Matt/hover2.png
>
> However reciently I've been pointed to this work done in Realsoft 3D
>
> http://www.matthias-kappenberg.de/index.php?id=165
>
> Can anyone here tell how he pulled off this effect?  And better yet can it
> be copied in POV-Ray?
>
> Thanks,
> Carl

An alternate solution to those already posted is to try to reproduce the
process used for the original TRON images.  The gridlines are 2D objects
pasted onto the image plane (i.e. your computer screen), not onto the floor
plane. As a result, the gridlines don't become "flat" as they approach the
horizon. So, why not use physical 2D objects (clipped planes?) for the
gridlines, and rotate them so that their normals are always perpindicular
to the camera?  I'm not sure how easy this is to accomplish, but this would
maintain thier "thickness" as viewed from the camera for the horizontal
lines, while the lines leading away from the camera would decrease in
thickness as required.  The problem with patterns is that they sit on the
ground plane and have zero "height" as they approach the horizon.

Or, you may just have to settle for something that looks "close enough" as
many of the posted solutions do.

Mike

Post a reply to this message

"Mike Sobers" <sob### [at] mindspringcom> wrote:
>
> An alternate solution to those already posted is to try to reproduce the
> process used for the original TRON images.  The gridlines are 2D objects
> pasted onto the image plane (i.e. your computer screen), not onto the floor
> plane. As a result, the gridlines don't become "flat" as they approach the
> horizon. So, why not use physical 2D objects (clipped planes?) for the
> gridlines, and rotate them so that their normals are always perpindicular
> to the camera?  I'm not sure how easy this is to accomplish, but this would
> maintain thier "thickness" as viewed from the camera for the horizontal
> lines, while the lines leading away from the camera would decrease in
> thickness as required.  The problem with patterns is that they sit on the
> ground plane and have zero "height" as they approach the horizon.
>
> Or, you may just have to settle for something that looks "close enough" as
> many of the posted solutions do.
>
> Mike

Or better yet, cylinders, since they will always have the same area normal
to the image plane regardless of viewing elevation angle.

See http://news.povray.org/web.44b28792e4538ab61009749b0%40news.povray.org
in the binary images section.  Of course, your cycles will have to ride
"over" the gridlines, since they're 3D, but depending on the camera
perspective it may not be noticeable.

Mike

Post a reply to this message

"Mike Sobers" <sob### [at] mindspringcom> wrote:
> An alternate solution to those already posted is to try to reproduce the
> process used for the original TRON images.  The gridlines are 2D objects
> pasted onto the image plane (i.e. your computer screen), not onto the floor
> plane.

If that's correct why are there shadows on the grid lines in TRON?

http://digitalstratum.com/images/tron/screenshots/hover_5.png

They look to be 2D objects pasted on the floor plane to me.

Thanks for all the work guys I still need to do my part and try to digest
everyone elses posted solutions but so far I don't think anyone has
actually reproduced the process used for the original TRON images.
Considering how "primitive" the raytracing software MAGI used back then
must have been by today's standard it amazes me sometimes just how hard it
is to copy what they did with today's software.

Thanks again,
Carl

Post a reply to this message

Ok see my latest try over in the image area.

Or here: http://www.wwwmwww.com/Matt/test1.png

I thought I'd give media filled cylinders a try and it doesn't look that bad
until you put something on the game grid and look close.  However I now have
another idea that I'm optimistic might work.  But I think I need some help
with the math.

Lets assume we make the grid using an object patern applied to the plane.
For the object we can use two arrays of cylinders.  Something like this:

    #local r=0.01*block_size;
    #local i=0;
    #while (i<z_grids+0.5)
      cylinder {<0,0,i*block_size>,<x_length,0,i*block_size>, r}
      #local i=i+1;
    #end

    #local i=0;
    #while (i<x_grids+0.5)
      cylinder {<i*block_size,0,0>,<i*block_size,0,z_length>, r}
      #local i=i+1;
    #end

However lets have each cylinders radius be a function of the distance from
the camera to the closest point on that cylinder to the camera.  Now lets
say I have the camera at <x1,y1,z1>.  Each cylinder is defined by 2 points.
 Something like <0,0,zA> and <Constant,0,zA>.  Hmmm... I think I may have
just answered my own question.  The closest point along that line would be
<x1,0,zA> wouldn't it?  Now... to think about what that function should be.
 Any ideas?

Off to try a few more things myself...
Carl

Post a reply to this message

"Carl" <car### [at] semisouthcom> wrote:
> "Mike Sobers" <sob### [at] mindspringcom> wrote:
> > An alternate solution to those already posted is to try to reproduce the
> > process used for the original TRON images.  The gridlines are 2D objects
> > pasted onto the image plane (i.e. your computer screen), not onto the floor
> > plane.
>
> If that's correct why are there shadows on the grid lines in TRON?
>
> http://digitalstratum.com/images/tron/screenshots/hover_5.png
>
> They look to be 2D objects pasted on the floor plane to me.

That's because the shadow is pasted on _top_ of the grid lines.  That's what
z-buffering is all about! See http://en.wikipedia.org/wiki/Z-buffering

>
> Thanks for all the work guys I still need to do my part and try to digest
> everyone elses posted solutions but so far I don't think anyone has
> actually reproduced the process used for the original TRON images.
> Considering how "primitive" the raytracing software MAGI used back then
> must have been by today's standard it amazes me sometimes just how hard it
> is to copy what they did with today's software.

I may be wrong, but I doubt that in '82 they were using raytracing for these
CGI animations (hard to believe I was only 7 then ;) ).  That's why it's
hard to reproduce the effects using a raytracer (same reason why games
don't use raytracing - it's too slow).  The process they were probably
using is effectively what OpenGL and Direct3D do today. It's equivalent to
cutting out little pieces of colored paper and arranging them on your desk,
then snapping a picture.  That's why the perspective (i.e. disappearing grid
lines) doesn't have to match reality - the shape you cut out for the little
pieces is totally up to you, but matching a real perspective view helps
improve the image.  That's why I think the original gridlines were not
produced by a raytracing engine (evidenced by the fact that they don't get
infinitly thin as they approach the horizon) but instead by the process I
was trying to describe above.  That's why I say the TRON gridlines aren't
_on_ the floor.  They tried to make them _look_ like they're on the floor,
and they got pretty close, but not as close as actually putting them on the
floor like POVRay does.

Mike

P.S. - great work, it's got a lot of us really thinking!  I think I may have
to go rent TRON again.

Post a reply to this message

"Mike Sobers" <sob### [at] mindspringcom> wrote:
> I may be wrong, but I doubt that in '82 they were using raytracing for these
> CGI animations (hard to believe I was only 7 then ;) ).

You are half-wrong (I think):

http://www.3gcs.com/tron/publications/time-life/index.htm

The company that did the lightcycles used a method to model and render them
that sounds suspiciously like raytracing of CSG-based objects.

> That's why it's hard to reproduce the effects using a raytracer
> (same reason why games don't use raytracing - it's too slow).

I think at the time raytracing was competitive because the alternative used
so much more memory.

Tom

Post a reply to this message

"Tom York" <alp### [at] zubenelgenubi34spcom> wrote:
> "Mike Sobers" <sob### [at] mindspringcom> wrote:
> > I may be wrong, but I doubt that in '82 they were using raytracing for these
> > CGI animations (hard to believe I was only 7 then ;) ).
>
> You are half-wrong (I think):
>
> http://www.3gcs.com/tron/publications/time-life/index.htm
>
> The company that did the lightcycles used a method to model and render them
> that sounds suspiciously like raytracing of CSG-based objects.
>
> > That's why it's hard to reproduce the effects using a raytracer
> > (same reason why games don't use raytracing - it's too slow).
>
> I think at the time raytracing was competitive because the alternative used
> so much more memory.
>
> Tom


Tom,

You're right about the cycles - great article.  So, they used primatives for
the cycles, probably the rest of the scene used raytracing as well.  Maybe
they used physical objects for the gridlines too (like the example of using
cylinders)?  They could have forced the gridlines to always be behind the
cycles and shadows by either rendering the cycles and background
separately, or by some other z-buffering technique.  There's definitely
something different about the way they did it versus the textured plane
scene in POV-ray, since I'm sure they didn't go to the effort of creating a
texture pattern with variable width gridlines.  Now if we could just figure
it out ... ;)

Mike

Post a reply to this message