I'm sorry, but it just gets on my nerves when people ignore my posts
completely. You only scratched the surface about how cool it would be
and you said nothing truly concrete. Could you please look at the link I
provided and tell me if you think this can be done? I just want a yes or
no. And I don't think you have to use triangles to do it. It could be
some sort of derivative of  implicit surfaces or something. Anyway,
thanks to those who really stuck to the original subject of the post.

Post a reply to this message

On Mon, 29 Mar 1999 13:18:04 -0500, Anthony Bennett 
	<ben### [at] panamaphoenixnet> wrote:
>I'm sorry, but it just gets on my nerves when people ignore my posts
>completely. You only scratched the surface about how cool it would be
>and you said nothing truly concrete. Could you please look at the link I
>provided and tell me if you think this can be done? I just want a yes or
>no. And I don't think you have to use triangles to do it. It could be
>some sort of derivative of  implicit surfaces or something. Anyway,
>thanks to those who really stuck to the original subject of the post.

I looked at the link you provided.  It describes a method and data
structure for managing the massive number of triangles generated by
displacement mapping.  This, of course, presupposes that you're 
working with meshes.  It does make mention of other papers that discuss
attempts to perform displacement mapping without triangles, but then
notes that those methods require tracing a curved ray, which usually
requires an iterative (read: slow and potentially inaccurate) process.

A footnote to the paper (footnote 1, page 4 of 10) notes that it could
be applied to curved surfaces as well as triangles, but by this I'm 
assuming they mean patches of some sort.  Even if they didn't, you'd
still need to write a subdivision routine for each primitive you would
want to displace - it's probably easier to just write a "create mesh"
routine for each such primitive.

I also note that the method documented in the paper doesn't work as
efficiently with a raytracer that renders a line at a time, as POV does
(and is constrained to do by large chunks of code.)

Post a reply to this message

I think that adding displacement maps to POV would be great.  It would first
require POV to be able to convert any object to a mesh (which can be
difficult, especially with CSG objects).  Whether the memory-saving
techniques described in this paper could be applied is a good question
(I have only read the abstract so far, so I don't know).

-Nathan

Anthony Bennett wrote:
> 
> I'm sorry, but it just gets on my nerves when people ignore my posts
> completely. You only scratched the surface about how cool it would be
> and you said nothing truly concrete. Could you please look at the link I
> provided and tell me if you think this can be done? I just want a yes or
> no. And I don't think you have to use triangles to do it. It could be
> some sort of derivative of  implicit surfaces or something. Anyway,
> thanks to those who really stuck to the original subject of the post.

Post a reply to this message

Thank you very much for reading the paper. You are too cool, Mr. Parker.
Thanks for explaining this to me. It strikes me as odd that there is no way
of doing this. I would think that you could change the space occupied by an
object at a certain point by relating the displacement-mapped point and the
object's normal at that same point. Or maybe I'm way off, I really don't know
much about this stuff.

Post a reply to this message

Thank you for trying to help also, Mr. Kopp. =) Please see my reply to Mr.
Parker.

Post a reply to this message

Anthony Bennett wrote:
> 
> Thank you very much for reading the paper. You are too cool, Mr. Parker.
> Thanks for explaining this to me. It strikes me as odd that there is no way
> of doing this. I would think that you could change the space occupied by an
> object at a certain point by relating the displacement-mapped point and the
> object's normal at that same point. Or maybe I'm way off, I really don't know
> much about this stuff.

  I don't think that he said there is no way to impliment the function.
The amount of work it would take and the major changes to the core of
the program would make one hesitate to consider if it is worth it. If
there were other processes and functions that could be added that would
take advantage of the major changes it might jusify the work but for a
stand alone feature it seems doubtful.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Tue, 30 Mar 1999 12:34:35 -0800, Ken <tyl### [at] pacbellnet> wrote:
>  I don't think that he said there is no way to impliment the function.

True.  What I said was that there's no (feasible) way to implement the
function without making triangle meshes.  Even the infeasible ways only
work for displacement-along-normal types of maps.

>The amount of work it would take and the major changes to the core of
>the program would make one hesitate to consider if it is worth it. If
>there were other processes and functions that could be added that would
>take advantage of the major changes it might jusify the work but for a
>stand alone feature it seems doubtful.

Well, the feature in question is quite powerful and would probably make
it all worthwhile.  You know all those nonlinear transforms people are 
always asking for, the stretches and bends and twists and morphs and
what-have-you?  They're all various kinds of displacement maps.  And once 
you've added the mesh-generation code to each[1] primitive object, just[2] 
add a CSG intersection function that operates on meshes and you can also 
have an OpenGL or wireframe preview or a "Create mesh" function like 
Polyray has.

[1] Or at least most of them.
[2] "Just." Ha! This is the hard part!

Post a reply to this message