help-3dldf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[help-3dldf] Re: Rotations


From: Hans Aberg
Subject: [help-3dldf] Re: Rotations
Date: Wed, 18 Aug 2004 18:52:12 +0200

At 01:57 +0200 2004/08/18, Laurence Finston wrote:
>Ray-tracing is one of the rendering techniques that I'll have to look into.
>I did look into this some time ago, but not very deeply.  It will be quite
>awhile before I get the point where I can implement rendering within 3DLDF.
>
>My impression was that all of the practical and commonly used rendering
>techniques work on pixel-data, that is, the image must be rasterized before
>they can be applied.  I don't remember specifically whether this applies to
>ray-tracing, but I think it does.

I think it has moved beyond that: That simple technique results in surfaces
that look very plastic. If one wants to create surfaces with different
textures, more advanced techniques are used. That is where that small
mirror technique came. But it was a long time I saw it. I can do much more
advanced things these days, like creating the flow of water, etc.

>Ultimately I will have to perform rasterization in order to implement
>high-quality rendering, but one of the constraints on 3DLDF is that I always
>want it to be able to produce output in the form of MetaPost code.   While I
>believe that high-quality rendering requires rasterization, there is quite a
>bit one can do without it.  For example, it should be possible to implement
>surface hiding by writing functions for "decomposing" geometric objects until
>none of them intersect.  Then they can be rendered by a simple painter's
>algorithm.   It may not be possible to do this at all in some cases, and in
>others it may not be possible with a reasonable number of iterations.

It might be done by a technique similar to the ray tracing method I
described: Starting from the eye, one seeks out the various points defining
the objects. One then probably need a way to compute the intersection
points between an object and the ray from the eye.

>I've already implemented reflection in a plane
>for `Points', but  haven't gotten around to "propagating" it through the other
>classes yet.  The problem is handling the case where the parts of a reflection
>that extend beyond the boundaries of a section of the plane must be "cut off".
> This is related to the problem of "decomposing" objects for surface hiding.

Is it not possible to have an infinite plane (or limited by available float
values), and make reflections in that plane? Then cutoffs will take place
when projecting it down to 2D.

>I find it more interesting to work with non-rasterized data, but it seems that
>beyond a certain point it will be necessary to use raster methods to get
>high-quality results.

I think that the ideal would be only work with objects defined by NURBS
points or something like that in float-space. This is what would correspond
to object constructions of fonts symbols. Rasterized fonts are rather
spacey at high resolutions.

  Hans Aberg






reply via email to

[Prev in Thread] Current Thread [Next in Thread]