|
![](/i/fill.gif) |
On Wed, 4 Jun 2003 13:32:10 -0700, "Ray Gardener" <ray### [at] daylongraphics com>
wrote:
> Sorry, I meant 'procedural' in the user-definable sense.
> POV-Ray's procedural textures are predefined.
>
> To be fair, I thought I remembered reading
> somewhere that POV 3.5 let textures use
> user-defined functions, although just going
> through the docs again I can't find
> references to that.
http://www.povray.org/search/?s=user-defined
> There's definitely
> no displacement shading, at any rate,
> except with isosurfaces (more below).
I think, you are mistaking texturing ang geometry in SDL syntax (thought they
are connected in reality). You can use the same informations for create both but
you will not find information about changing geometry in chapters about creating
textures.
> > You like procedural geometry but don't like isosurfaces?
>
> Well, isosurfaces have a sampling function interface
> analogous to regular shading in Renderman. For some
> shapes, this is preferable -- e.g., a sphere is
> just x^2 + y^2 + z^2.
That's not equation of f_sphere but of f_r internal function.
And becouse you do not see difference you wrote next sentence.
> But for other shapes,
> determining from (x,y,z) whether the point is
> inside or outside gets complicated.
Actually test for inside/outside is far simpler then looking for intersection.
Inside are all points where value of function for given point is below value of
threshold. Outside are all points where value of function for given point is
over value of threshold. On surface are all points where value of function for
given point is equal value of threshold.
> POV-Ray might benefit from including a
> procedural geometry keyword
Adding one keyword does not change functionality. That's internall support of
keyword which makes feature useful ;-)
> which would
> have an option of emitting the geometry
> to the scene's object tree (for raytracing
> along with the other objects)
If permanently, why this can't be done by script?
> There would be a DLL (on win32) named landscape_detail.dll
> that would be passed the object, along with a reference
> to the zbuffer, the object tree, and cam/lighting.
> The DLL could then proceed to create whatever geometry
> it wanted, adding it to the tree or rasterizing it
> into the zbuffer (the bool arg after the DLL name indicates which).
You can read about adding support for dlls for example in this thread
http://news.povray.org/povray.programming/31596/
> The geometry_processing keyword would also be available
> outside global_settings, so that one could easily change
> the rendering manner for sections of a script in specific ways.
Two side notes, since number of your post increases can I ask you kindly about
making your lines longer? Is there any particular reason for you to use
sometimes less than 50 characters? It would make reading your long posts easier
for those who do not have wheel in mouse and use only keybord. Thanks.
And before you will start discuting all features you want discuss I just want to
told you about existence of povray.unofficial.patches and povray.programming
groups. Their existence is well described at
http://news.povray.org/povray.announce.frequently-asked-questions/
ABX
Post a reply to this message
|
![](/i/fill.gif) |