|
 |
Believe you've got the mesh thing right; that is, about it being the
reason the displacement hasn't been used.
Most primitives in POV being non-polygon and that conversion you mention
necessary means extra computing.
Anyone want to bet someone more in the know backs me up? Or maybe I will
lose my shirt in this gamble.
Hey, we'll all have computers beyond these puny 500MHz, 256Meg RAM
machines someday though, right? ha-ha, ah, uh...
Lance Birch wrote:
>
> Well, it could be done... all you have to do is specify the bounds of an
> object and an XYZ threshold. If there is an object intersection routine in
> POV-Ray (which there has to be somewhere!) then you could make a patch of
> POV-Ray to allow keyword access to such a function. Then all you have to do
> is an ordered test from the top of the bounding box to the bottom calling
> the routine. If it returns 1 then you know that the point lies on the
> surface of the object, so you can join the previous row of triangles to the
> current and so on... And there you have it, a MESH! WOO HOO!!!
>
> There is a plug-in for MAX called MAXMath which does exactly that. I've
> also made a small program that does it. It's not that hard (well, I've
> never done the meshing before, but I'm sure some talented programmer out
> there could).
>
> Not sure about fractals though... Hmm........
>
> Anyway, hope this helps! Oh, and also, you'd have to make some new mapping
> modes, like shrink-wrap to make it realy useful for displaycement mapping,
> or alternatively, you can have it as part of the texture statement.
>
> --
> Lance.
>
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aol com?Subject=PoV-News
Post a reply to this message
|
|
