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

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

[help-3dldf] Re: Rotations


From: Laurence Finston
Subject: [help-3dldf] Re: Rotations
Date: Wed, 18 Aug 2004 21:46:34 +0200
User-agent: IMHO/0.98.3+G (Webmail for Roxen)

Hans Aberg wrote:

> 
> I think it has moved beyond that: 

All of the advanced rendering techniques I've looked into require data to be
rasterized.  Ultimately, rendering is simply determining what color each pixel
should be and setting it.  Since the data must be rasterized anyway, and since
there are good rendering methods that operate on rasterized data, it makes
sense that these are the methods of choice today.

Before I can start implementing such methods I must implement rasterization in
3DLDF.  I probably wouldn't bother with geometric (or vector) methods if I
didn't want to make it possible to perform a limited form of rendering while
producing MetaPost output.

I do find that there's more scope for cleverness when dealing with geometric
objects.  Once objects are rasterized, it doesn't matter what they were
derived from.  However, maybe I'll find that raster methods have a charm of
their own, once I start working on them.

> 
> 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.

Yes.  This is one of the reasons I'm so interested in intersections.

> 
> 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.
> 

It may be possible to do some or all of the cutting-off following the
2D-projection.  I haven't thought this through yet.

> 
> 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. 

For some kinds of geometrical objects, I believe I may gain significantly
better performance for some operations by defining them specially, rather than
implementing them as NURBs.  For example, it is possible to use NURBs to
define perfect conic sections, but it may be possible to define functions for
finding their intersections that are more efficient than a function for
finding the intersections of NURBs.

> Rasterized fonts are rather
> spacey at high resolutions.
> 

This is one of the disadvantages of raster methods with respect to vector
methods.  It might be worthwhile to do as much as possible of the surface
hiding, reflections, and shadows (forgot to mention them before) using vector
methods before using the raster methods.

Laurence



reply via email to

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