Well, I've been looking through the Superpatch source code for a while
now, but from it I've gotten the distinct impression that anything not
currently possible in POV-Ray can be added with enough time and
imagination.
So is it possible now to add a primitive that can be used to do trees?

This isn't totally out of the blue. I do have a *vague* idea of how to
implement something like this, at least in abstract. No doubt many of
you are familiar with LParsers; why not create an lparse primitive that
can be made to create complex objects? Each object could have its own
random "seed" for the compilation process, wherein the Lparsing would be
done, creating a list of objects. Consider a structure like this:

struct LPARSE_STRUCT {
  ...	/* The usual object stuff */
  /* Random seed is not included here because it is used at compile-
     time only */
  LPARSE_DATA *Data;  /* Pointer to the parent object */
  LPARSE_OBJ *Obj;    /* First in a linked list of sub-objects */
}

struct LPARSE_DATA {
  LPARSE_BRANCH *Branch;  /* First in a linked list of branch objects */
}

struct LPARSE_BRANCH {
  <whatever datatype works> instructions;  /* LParser instructions */
  OBJECT *Obj;
  LPARSE_BRANCH *next;
}

struct LPARSE_OBJ {
  /* This is a pointer to the object, not the actual object. In theory,
     this could save a lot of memory. */
  OBJECT *Obj;
  /* Transformed from <0,0,0> of the lparse object's base */
  Transformation *Trans;
  LPARSE_OBJ *next;
}


The idea is this: The LPARSE_BRANCH is a type of object, only one
defined per lparse object. This object is referred to many times, and
exists in many places, within the LPARSE_OBJ list--but it's scaled and
rotated and translated in different ways in each LPARSE_OBJ structure.
Now when POV-Ray parses the scene and sees an lparse primitive, it will
set up the random seed and automatically create the list of LPARSE_OBJ
object pointers and their transformations.
Bounding boxes are of course important.
When rendering, the renderer will first look for the bounding box of the
main object. If it intersects that, it then checks all the objects in
the LPARSE_OBJ list, transformed properly into place. If it intersects
any of those, they are checked as if they're part of the list.

There are of course conceptual flaws. I haven't made a new primitive
before, so I'm not sure of all that's involved. But also, I'm not even
sure an object can be referenced like that in many different places,
with different transformations--can it?
As an example of what this primitive could do, I submit this pseudocode:

#declare tree=lparse {
    orientation_fwd y	// these vectors will get transformed
    orientation_right x //  during lparsing
    max_depth 7         // to keep the lparser from going berserk
    bounded_by {cylinder {...}}
    branch {           // tree trunk/branch
        instructions "..."   // heck, they're complicated
        object{...}
        }
    branch {           // twig--followed by a number of leaves
        instructions "..."   // similar to the ones above
        object{...}
        }
    branch {object{...}}  // leaf
    }

This, at present, is beyond my capability to add to the source code; yet
I suspect there's more than one person out there with the expertise to
do it.
The only severe worry is scale; there has to be some way of sending size
information to a branch, so it knows how it should be scaled down, or
how long or wide it should be. But a leaf, on the other hand, should
remain more or less the same scale always.

The thought of rendering a scene with real-looking trees in the
background really gets to me. If it could be done with a minimal amount
of memory per tree, yet still allowing each to be subtly different, why
not try it?
Any takers?

Lummox JR

Post a reply to this message

I have thought about doing this, but I know way too little about the
POV-Ray source code to even add a keyword, and have only recently
successfully compiled it.

Post a reply to this message

If this feature is implimented, you should be able to specify at what
recursion depth the different types of branches/leaves kick in.

Post a reply to this message

Edward C. wrote:
> 
> If this feature is implimented, you should be able to specify at what
> recursion depth the different types of branches/leaves kick in.

Absolutely. But it's been a long time since I've worked with an LParser,
so I'm not 100% clear on the code I would use to do this. Otherwise I'd
have included some pseudocode for the instructions, too.
My only other thought here is that if POV-Ray can't do the Lparsing,
there should at least be some way to implement the structure itself, so
that memory is used as efficiently as possible for objects lparsed by an
outside program.

Lummox JR

Post a reply to this message

Another thing I think would be a good idea is a built in particle
system, which would simulate fire, smoke, water, etc. Hmm, even an
scene_interaction keyword to make the particles respond to objects in
the scene?

Post a reply to this message

Chris Huff <Chr### [at] compuservecom> wrote:
: Another thing I think would be a good idea is a built in particle
: system, which would simulate fire, smoke, water, etc. Hmm, even an
: scene_interaction keyword to make the particles respond to objects in
: the scene?

  and kinematics and inverse kinematics and physics laws and...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff wrote:
> 
> Another thing I think would be a good idea is a built in particle
> system, which would simulate fire, smoke, water, etc. Hmm, even an
> scene_interaction keyword to make the particles respond to objects in
> the scene?

Well, fire's possible now. I've got a nice campfire scene using some
simple media and isosurfaces (via the Superpatch).

Lummox JR

Post a reply to this message

Yes, but I think a particle system would be more realistic, at least for
animations. I have been writing a pretty nice particle system, but it is
in C++. Maybe I will add it when POV-Ray is converted to C++.

Post a reply to this message

An interesting idea, and possible to implement of course!

But what are the advantages and disadvantages of implementing
L-parsing as a macro vs POV native primitive?  Would we want
to encourage one approach to L-Parsing as decided by the POV
team?

--
Nigel Stewart (nig### [at] eisanetau)  http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.

Post a reply to this message

Primitive Pros:
    MUCH faster parsing
    would probably take less memory
    would be easier to use the object parameters
    could be made much more powerful
    would have the standard object syntax

Macro Pros:
    easily updated
    people without a compiler could modify it
hmm, that is all I could think of.

Post a reply to this message

Chris Huff wrote:
> 
> Primitive Pros:
>     MUCH faster parsing
>     would probably take less memory
>     would be easier to use the object parameters
>     could be made much more powerful
>     would have the standard object syntax

It's not so much the parsing speed that concerns me, as the memory
issue. Objects in POV-Ray are huge; a forest full of Lparsed trees would
be enormous, if each tree consisted of 500 objects. If each tree,
however, merely consisted of 500 transformations and pointers to
objects, and the entire forest only took up 3 or 4 physical objects (the
tree sections) plus the trees themselves, then it might just work.
Plus, the amount of memory used has some effect on the rendering speed.
But it's probably quicker to check for intersections with an internal
array of 500 object pointers and transformations than with 500 other
objects on the whole list.
Also, there is the great advantage that bounding volumes could be
applied to each branch in the same manner (hmm... best make that an
additional item in the array elements), speeding up rendering time
somewhat.

The biggest problems, I think, are these:

1.) Trying to provide parameters to the branch objects. These might be
    made intentionally variable depending on their position, depth in
    the structure, etc. It might actually be necessary to define a
    special type of object for Lparser branches, to allow for this.
2.) Creating seamless intersections. A tree doesn't just look like a
    bunch of tinkertoy cylinders strung together. Rather, it might look
    more like a blob object (hmm.... an interesting idea) with some
    random noise to it. Where a branch goes off from the trunk, there's
    a "neck" to the branch where the trunk curves outward--and when it
    does go in a new direction, the texture smoothly goes with it.
    Perhaps an Lparse blob type of object would be in order?

This actually gives me an idea--it might be possible to update the blob
type to include isosurfaces as per the Superpatch. With that, functions
can be used to affect the density. That might not help with this
particular problem, but I like the idea of what it could do elsewhere.

> Macro Pros:
>     easily updated
>     people without a compiler could modify it
> hmm, that is all I could think of.

I think "easily updated" would apply just as easily to the primitive,
too.

Post a reply to this message

On Mon, 28 Jun 1999 14:02:52 -0400, Lummox JR wrote:

>This actually gives me an idea--it might be possible to update the blob
>type to include isosurfaces as per the Superpatch. With that, functions
>can be used to affect the density. That might not help with this
>particular problem, but I like the idea of what it could do elsewhere.

Uh... a blob _is_ an isosurface.  It's just a specialized one that
has been optimized to be faster to compute than a general isosurface.

Post a reply to this message

In article <3776DBE4.5A7D7C7E@eisa.net.au>, Nigel Stewart
<nig### [at] eisanetau> wrote:

>An interesting idea, and possible to implement of course!
>
>But what are the advantages and disadvantages of implementing
>L-parsing as a macro

I just converted an old IFS-fractal type program I wrote *many* years ago
(for OS-9, on a Tandy Color Computer, if anyone remembers) into a macro on
POV. I'll try and post the macro later on. (It is on my home computer, not
my office computer.)

It implements both 'building' the fractal, and 'fading in' to the fractal
(Bernhard's method, or something?)

Makes some pretty cool shapes (especially when used with blobs) but it is
nowhere near making real trees yet.

Jerry

Post a reply to this message

<jer### [at] cerebusacusdedu> <jer### [at] acusdedu> wrote:
> I just converted an old IFS-fractal type program I wrote *many* years ago
> (for OS-9, on a Tandy Color Computer, if anyone remembers) into a macro on
> POV. I'll try and post the macro later on. (It is on my home computer, not
> my office computer.)

Posted in povray.binaries.scene-files under the subject "Fractal Macro".

Jerry

Post a reply to this message

Ron Parker wrote:
> Uh... a blob _is_ an isosurface.  It's just a specialized one that
> has been optimized to be faster to compute than a general isosurface.

True, true.
I was thinking, though, something along the lines of both: Something
with a blob's clipping capabilities, and the ability to hold multiple
components, yet using the power of functions.

Ironically, right now I'm looking through the blob code, seeing if
there's a way to add a torus-shaped component. Imagine the
possibilities. Most of it is pretty straightforward, but at the moment
I'm a bit stuck on the math of trying to get the quartic coefficients
right for All_Blob_Intersections. I can't seem to get anything less than
an 8th order equation to work mathematically, even though a 4th order
equation ought to do the trick. I'll keep at it, of course....   :)

Lummox JR

Post a reply to this message

Jerry wrote:
[snip]
> Makes some pretty cool shapes (especially when used with blobs) but it is
> nowhere near making real trees yet.

Interesting....
Ideally, though, I think to get a forest of realistic trees, some sort
of mutant isosurface with component lists is needed. Something like a
blob, perhaps, in its ability to ignore certain elements that can't
intersect the ray. The up side is that if it's done like a blob, it can
be possible to texture the individual elements.

Lummox JR

Post a reply to this message

On Tue, 29 Jun 1999 23:34:14 -0400, Lummox JR wrote:
>Ron Parker wrote:
>> Uh... a blob _is_ an isosurface.  It's just a specialized one that
>> has been optimized to be faster to compute than a general isosurface.
>
>True, true.
>I was thinking, though, something along the lines of both: Something
>with a blob's clipping capabilities, and the ability to hold multiple
>components, yet using the power of functions.

Isosurfaces can be used in CSG.  In some cases you'll have to tell it
explicitly to find all intersections to get it right, but it will work.

>Ironically, right now I'm looking through the blob code, seeing if
>there's a way to add a torus-shaped component. Imagine the
>possibilities. 

While you're in there, add a conical component.

Post a reply to this message

On Tue, 29 Jun 1999 23:40:09 -0400, Lummox JR wrote:
>Jerry wrote:
>[snip]
>> Makes some pretty cool shapes (especially when used with blobs) but it is
>> nowhere near making real trees yet.
>
>Interesting....
>Ideally, though, I think to get a forest of realistic trees, some sort
>of mutant isosurface with component lists is needed. Something like a
>blob, perhaps, in its ability to ignore certain elements that can't
>intersect the ray. The up side is that if it's done like a blob, it can
>be possible to texture the individual elements.

I was thinking just this last night as I was driving across town to an
appointment, thanks to you (cue the "You Know You've Been Raytracing Too 
Long" thread...)

Keep in mind that blobs don't actually texture the individual elements.
I think they texture each intersection based on a weighted average of 
the textures on the components that contributed to that intersection,
though I'll admit that that's one area of the code that I don't have
memorized yet.

Post a reply to this message

On 30 Jun 1999 09:56:28 -0400, par### [at] fwicom (Ron Parker) wrote:

<snip>
>
>While you're in there, add a conical component.  

Polygonal, too.


Peter Popov
ICQ: 15002700

Post a reply to this message

Ron Parker wrote:
> While you're in there, add a conical component.

Cones should work out, although I had to give up on toruses.
Problem is, density is a 4th-order polynomial, and density of a torus
can't be defined that way; it can't even be fudged easily. I think
2nd-order object types are the limit.
Well, there's always isosurfaces.

Right now I'm checking to see if maybe I can't create an "isoblob" type
that mixes the two. This is a bit weighty a task, I know, but the idea
is solid.
The concept is not only that the isoblob will contain some simple
structures like a blob, but that each will have a function (or rather, a
pointer thereto), a special bounding object, etc. The bounding objects
will be handled just like the blob types, but within each interval of
influence will be an addition of density functions (weighted by a
strength value).
I think this may be vaguely within my capability. It will take some
serious combinations of the isosurface and blob code, but most of the
work is already done in some way or another. I seem to understand most
of the blob code I've looked through, which is encouraging.

The main idea here, BTW, is that an isoblob will be able to contain
*many* components, perhaps built by a macro, many of them using the same
functions. (The only catch is that there might need to be a
non-translated vector input to the function as well as translated, to
take advantage of functions like noise3d() in blob space rather than in
component space.)

Lummox JR

Post a reply to this message

Ron Parker wrote:
> Keep in mind that blobs don't actually texture the individual elements.
> I think they texture each intersection based on a weighted average of
> the textures on the components that contributed to that intersection,
> though I'll admit that that's one area of the code that I don't have
> memorized yet.

Hmm... I think you're right.
Perhaps there might be a flag in an element to prevent it from blending
textures?
Actually, it seems to me that a decent tree would need the leaves to be
something separate anyway, since there's little point in blending in the
leaf shape with the branch shape. Two separate isoblobs would do the
trick... but how would that be built via a macro?
All idle speculation at this point. I can do only limited work on the
isoblob idea this week, and anyway I've only *just* begun to look into
the idea. But it's an idea that I *really* like.

Lummox JR

Post a reply to this message

Sounds like a Very Good Idea. It would be wonderful for all sorts of
organic shapes.

Post a reply to this message

On Wed, 30 Jun 1999 23:56:43 -0400, Lummox JR wrote:
>Perhaps there might be a flag in an element to prevent it from blending
>textures?

I don't think you could.  How would you color the "neck" that connects
two components?  It's not really a part of either component.

>Actually, it seems to me that a decent tree would need the leaves to be
>something separate anyway, since there's little point in blending in the
>leaf shape with the branch shape. Two separate isoblobs would do the
>trick... but how would that be built via a macro?

I think you'd just need two macros.  One that generates the branch 
structure and puts blobby elements where the branches would be, and one
that generates the same branch structure and puts blobby elements where
the leaves would be.

>All idle speculation at this point. I can do only limited work on the
>isoblob idea this week, and anyway I've only *just* begun to look into
>the idea. But it's an idea that I *really* like.

Another idea, and one that might be better able to leverage the blob code:
add an isosurface component to the existing blob syntax.  Then you can use
the existing blob algorithms when the only components in range are the usual
spherical and cylindrical ones, and kick it into repeated-subdivision mode
only when there's a complex component in range, passing the existing 
isosurface code a custom-made function that is the sum of the functions for 
the relevant components.  Ideally, you'd find some way to cache the 
custom-made function for a while in case the same set of components gets hit 
again soon, but that's just an implementation detail.

Post a reply to this message

Ron Parker wrote:
> Another idea, and one that might be better able to leverage the blob code:
> add an isosurface component to the existing blob syntax.  Then you can use
> the existing blob algorithms when the only components in range are the usual
> spherical and cylindrical ones, and kick it into repeated-subdivision mode
> only when there's a complex component in range, passing the existing
> isosurface code a custom-made function that is the sum of the functions for
> the relevant components.  Ideally, you'd find some way to cache the
> custom-made function for a while in case the same set of components gets hit
> again soon, but that's just an implementation detail.

That's quite true; that could work. Only then there's the problem of
isosurfaces with different bounding shapes, etc. Also, I suspect that
including mixed element syntax could slow things down when only one form
or the other was needed.
For most cases, I think a simple isoblob might make more sense. Any
shape that would use that many functions together would likely be meant
to look rather different from the artificial shape types in a blob;
isoblobs would probably be used only for organic shapes, like trees, or
else for shapes that use toruses and other unsupported blob components.

Lummox JR

Post a reply to this message

Ron Parker wrote:
> While you're in there, add a conical component.

I've done a little bit of preliminary math on the conical blob component
idea. It shouldn't be excessively difficult to add.
The result won't look *entirely* conical, because the r function looks
like this:

r^2 = (x^2+y^2)+(1-z)^2

I think the sides of the cone, when r<1, will curve inward a little bit.
I haven't done a complete analysis of the curve; just some rough figures
on paper. Still, it ought to do.
I also did a little math on the idea of a paraboloid element; why not?
Then "r" is defined thusly:

r^2 = (x^2+y^2)+(1-z)

That one should keep more of a true shape as r gets lower.
In each of these, I think I'll need to add a way to cap off both ends,
and create a flat plane there (or really, more like the cylinder
element's cap hemispheres).
Because of that, the ideal cone would actually have a density of 1 all
through the center, but that's not possible because of the math
involved. The formula would be r^2=(x^2+y^2)/z^2 -- and since r^4 and
r^2 are both used in a fourth-order equation, things would get kind of
tricky. There'd be no real way to isolate r^2, either, and still get any
kind of a polynomial, which was my problem with the torus idea.
Gads, this stuff gets hairy....

Lummox JR

Post a reply to this message

Hmmm ... I read this group now a while, and I think the treeIdea is not as
bad ...
especially the idea that not only to use cylinders but blobs for use as the
branches is important, I think ...
But there I got an Idea to offer ...

Why Use the Tree in the Geometrics Part of PoV?? Why create a Geometric
Object ???

Can't we use it as a kind of Media ???
I think this way: I just create a hollow cube, assignin' a texture with a
media. This media is computed by the new tree-Algo with will (with the right
DensityMap) show a nice tree. One Pro would be that, by adding an noise to
this, you can create a relative natural taste of it ...

But I'm sure there are enough Contras to this(just thinking on the speed).


Now it's on you, the masters, to decide about this dumb Idea of a novice ;-)

PS.: Sorry 'bout my bad english ... I'm from germany, you see...

Post a reply to this message

"Jan Walzer" <nos### [at] informatikuni-hallede> writes:

> Hmmm ... I read this group now a while, and I think the treeIdea is not as
> bad ...
[...]
> Can't we use it as a kind of Media ???

You're not the first one to come up with this idea. It has already be
phrased by Kajiya and Kay in "Rendering Fur with Three Dimensional
Textures", Computer Graphics, Volume 23, Number 3, July 1989.

I'm currently working more or less (read: less) on an implementation
of the fur that is presented in this paper. A short film of a furry
torus can be seen at http://www.povray.willhalm.de/tracegallery/ .

In my opinion, this approach has a lot of potential. Apart from fur,
I think that grass and forests can be renderered this way. Of course,
someone must first find an adequate lighting model for these objects.
However, you should be aware that this method will only work for 
distant views.

> PS.: Sorry 'bout my bad english ... I'm from germany, you see...

dito.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

> > Can't we use it as a kind of Media ???
>
> You're not the first one to come up with this idea. It has already be
> phrased by Kajiya and Kay in "Rendering Fur with Three Dimensional
> Textures", Computer Graphics, Volume 23, Number 3, July 1989.
Where to get this paper ?

[...]
> In my opinion, this approach has a lot of potential. Apart from fur,
> I think that grass and forests can be renderered this way. Of course,
> someone must first find an adequate lighting model for these objects.
> However, you should be aware that this method will only work for
> distant views.
hmmm ... but am I right, about the rendertime ...
I've thougt about the last night, and found that therefore the "steps in the
media" (or how was it called) have to be massivly increased, to get all the
branches of a high-detailed tree, don't they?
The standard for this is AFAIK 10 steps, and how can this make a good tree ?

Post a reply to this message

> I'm currently working more or less (read: less) on an implementation
> of the fur that is presented in this paper. A short film of a furry
> torus can be seen at http://www.povray.willhalm.de/tracegallery/ .
maybe there's something wrong with your link ???

Post a reply to this message

In article <387ba7f6@news.povray.org>, "Jan Walzer" 
<nos### [at] informatikuni-hallede> wrote:

> hmmm ... but am I right, about the rendertime ...
> I've thougt about the last night, and found that therefore the "steps in 
> the
> media" (or how was it called) have to be massivly increased, to get all 
> the
> branches of a high-detailed tree, don't they?
> The standard for this is AFAIK 10 steps, and how can this make a good 
> tree ?

I really think the best use of a density pattern to make a tree or grass 
would be in an isosurface, which is actually slightly similar to media 
in some ways. And their render speed is usually quite tolerable, 
although complex ones with a lot of very small details can be slow.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

"Jan Walzer" <nos### [at] informatikuni-hallede> writes:

> > I'm currently working more or less (read: less) on an implementation
> > of the fur that is presented in this paper. A short film of a furry
> > torus can be seen at http://www.povray.willhalm.de/tracegallery/ .
> maybe there's something wrong with your link ???

I don't know. I tested it and it worked - and still works - fine for me.
There seems to be something wrong with the forwarding. So, try
http://www.fmi.uni-konstanz.de/~willhalm/graphics/tracegallery/
instead.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

"Jan Walzer" <nos### [at] informatikuni-hallede> writes:

> > > Can't we use it as a kind of Media ???
> >
> > You're not the first one to come up with this idea. It has already be
> > phrased by Kajiya and Kay in "Rendering Fur with Three Dimensional
> > Textures", Computer Graphics, Volume 23, Number 3, July 1989.
> Where to get this paper ?

First try the library of the university in Halle. If it's not available
there, you can get it using <insert what "Fernleihe" means in English>.
Alternatively, it may be downloadable with a credit card at www.acm.org,
because it's in a magazine that is published by the ACM (which I forgot to
mention). 
 
> [...]
> > In my opinion, this approach has a lot of potential. Apart from fur,
> > I think that grass and forests can be renderered this way. Of course,
> > someone must first find an adequate lighting model for these objects.
> > However, you should be aware that this method will only work for
> > distant views.
> hmmm ... but am I right, about the rendertime ...
> I've thougt about the last night, and found that therefore the "steps in the
> media" (or how was it called) have to be massivly increased, to get all the
> branches of a high-detailed tree, don't they?
> The standard for this is AFAIK 10 steps, and how can this make a good tree ?

I cannot speak for trees but for fur. Using media makes mainly sense, when
you don't care about details. Instead of a higly detailed image, you want
to look your fur (tree, grass, forest) good from a distance. So, you 
approximate the reflections instead of generating a lot of cylinders.

As far as I know, the number of steps is also calculated adaptively.
That's why I suspect the number of steps to be higher by default in
such applications. However, I didn't care about them too much so far.
I have tried the new sampling methods in the megapatch. They didn't
work very well in case of my furry torus.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

Chris Huff <chr### [at] yahoocom> writes:

> In article <387ba7f6@news.povray.org>, "Jan Walzer" 
> <nos### [at] informatikuni-hallede> wrote:
> 
> > hmmm ... but am I right, about the rendertime ...
> > I've thougt about the last night, and found that therefore the "steps in 
> > the
> > media" (or how was it called) have to be massivly increased, to get all 
> > the
> > branches of a high-detailed tree, don't they?
> > The standard for this is AFAIK 10 steps, and how can this make a good 
> > tree ?
> 
> I really think the best use of a density pattern to make a tree or grass 
> would be in an isosurface, which is actually slightly similar to media 
> in some ways. And their render speed is usually quite tolerable, 
> although complex ones with a lot of very small details can be slow.

I have tried to model the fur with an isosurface and failed miserably.
I don't know why this didn't work. With media however, it turned out
quite weill. For this reason, I believe that it may be worth the effort 
to try grass or needles with media.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

> > > The standard for this is AFAIK 10 steps, and how can this make a good
> > > tree ?
> >
> > I really think the best use of a density pattern to make a tree or grass
> > would be in an isosurface, which is actually slightly similar to media
> > in some ways. And their render speed is usually quite tolerable,
> > although complex ones with a lot of very small details can be slow.
>
> I have tried to model the fur with an isosurface and failed miserably.
> I don't know why this didn't work. With media however, it turned out
> quite weill. For this reason, I believe that it may be worth the effort
> to try grass or needles with media.
... and again this Object: "isosurface"
I've read a lot of this here in group, but I never heard something of this
before ...
Is it an extension of POV or have I to read for it in the standard POV-Docu?
Is it provided by any graphical frontend? I only seldom use Handcoding
...(yes, I use Moray)

But: What is an "isosurface" ? ...

PS: Don't answer if it is an RTFM-question ...

Jan

Post a reply to this message

Jan Walzer wrote:

> ... and again this Object: "isosurface"
> I've read a lot of this here in group, but I never heard something of this
> before ...
> Is it an extension of POV or have I to read for it in the standard POV-Docu?
> Is it provided by any graphical frontend? I only seldom use Handcoding
> ...(yes, I use Moray)
> 
> But: What is an "isosurface" ? ...
> 
> PS: Don't answer if it is an RTFM-question ...
> 
> Jan

An isosurface is a mathematical surface representation that conforms to a
set of predefined rules. Isosurfaces are not currently available in the
official version of POV-Ray. Isosurfaces are currently only available in
unofficial versions of the program but will most likely be included in
the next official release POV-Ray.

You can visit the original home page of the isosurface for specifics on
the subject -

http://www.public.usit.net/rsuzuki/e/povray/iso/index.html


And if you want to try using them in your work now there are currently
four platforms that you can find an updated patch that has Isosurfaces
available -

For the Windows OS -
http://nathan.kopp.com/patched.htm

For the Dos OS
http://www.sgib.co.uk/

For the Unix/Linux OS
http://www.mailbag.com/users/mtgordon/megapov.html

For the Mac OS
http://users.skynet.be/smellenbergh/main.html

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message