![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff wrote:
>
> In article <3d75ef48@news.povray.org>,
> "Thorsten Froehlich" <tho### [at] trf de> wrote:
>
> > > I'm not sure what "hypertextures" are
> >
> > See the book "Computer Graphics, Principles and Practice" (1990) or
> > "Hypertexture" by Ken Perlin in ACM SIGGRAPH Computer Graphics 23, July
> > 1989.
>
> I'll look for those, but my chances of finding them are slim. Any web
> sites or online papers?
http://mrl.nyu.edu/~perlin/doc/hypertexture/ ?
--
Ken Tyler
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3D76AF80.A953620E@pacbell.net>, Ken <tyl### [at] pacbell net>
wrote:
> http://mrl.nyu.edu/~perlin/doc/hypertexture/ ?
Thanks...I should have expected that response, I guess. ;-)
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"ABX" <abx### [at] abx art pl> wrote...
> On Fri, 30 Aug 2002 03:29:33 -0400, "William F. Pokorny"
> <pok### [at] attglobal net> wrote:
> > I believe Pov-Ray uses a 4 by 4 matrix of doubles internally for each
transform
> > of anything.
>
> Every transformation structure contains 2 matrixes: normal and inversed
one.
And, because of uv mapping, each object has two (yes, two) transformations.
The truth is that with better planning and a proper class inheritance model,
the memory usage could probably be greatly decreased for certain objects
(spheres being one type).
-Nathan
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3d76d3c3$1@news.povray.org> , "Nathan Kopp"
<pov### [at] nkopp mailshell com> wrote:
> And, because of uv mapping, each object has two (yes, two) transformations.
>
> The truth is that with better planning and a proper class inheritance model,
> the memory usage could probably be greatly decreased for certain objects
> (spheres being one type).
Actually, spheres do not have them if the are just translated or scaled
uniformly...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> I'm not sure what "hypertextures" are, but I think they have something
> to do with actually deforming the surface of the object. POV is a
> raytracer that traces most shapes directly, it doesn't reduce everything
> to triangles, so doing real deformation would require tesselating the
> objects into a triangle meshe or tracing curved rays.
I was just thinking how media works: a ray hits an object, several samples
along the ray are taken, and the light along the ray is calculated. This
takes time, but with GHz PCs...
Just thinking aloud: A ray hits an object (say, a sphere). A second sphere
which is a little smaller is tested against the same ray. Now I know a
finite segment of the ray that is inside the "boundary" of the sphere. I'd
apply a root solver to e.g. the leopard pattern plus the distance to the
inner sphere along that finite segment (I'm afraid this isn't even close to
being mathematically correct, I hope you can see what I mean...). So now I
have the intersection of a sphere with a "leopard" hyper-texture. Of couse
this is slow, but currently I'm using millions of spheres, which is probably
slower (at least as soon as windows starts swapping).
I don't have a clue what that would look like, really, but I could imagine
some interesting effects could be done with that...
> Are you talking about built-in
> isosurface functions for making displaced versions of the basic
> primitives, so a user defined function doesn't have to be interpreted?
Yes, close. Pigments like granite or ripples aren't interpreted either.
There's one thing isosurfaces can't do: you can't wrap them around a
height_field.
I also think wraping an isosurface around the boundary of a primitive should
be faster because the boundary is smaller than the whole object, so less
space has to be tested against some function etc.
Last but not least, you could build a scene with primitives (spheres,
cylinders, height_fields...) and test the "iso-textures" (?) separately on
some spheres, applying them the primitves when you got the geometry and
colouring right (that's exactly how I use the media and radiosity features
right now).
You could even build include files for often used "iso-textures" (I seem to
like that name) and apply them to any object you like (which is quite hard
with iso-surfaces)
Again, I can't say that often enough: What I'd like to do isn't fast, not at
all. However, if I'd like to do something like that with pov-ray right now,
I have to use uncounted triangles or spheres or isosurfaces which aren't
fast either, and are also a bit hard to use.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Thu, 5 Sep 2002 16:49:26 +0200, "Niki Estner" <nik### [at] freenet de>
wrote:
> There's one thing isosurfaces can't do: you can't wrap them around a
> height_field.
Perhaps I don't understand what you are trying to say but I think otherwise.
ABX
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3d777099@news.povray.org>,
"Niki Estner" <nik### [at] freenet de> wrote:
A similar idea, but much faster: use the normal perturbation pattern to
perturb the intersection distance. The outline of the object and its
shadow would be unaffected, but it would make a difference in CSG and
when another object is partially penetrating it, like a sphere embedded
in a plane. It would probably be too obviously fake to be worth
anything, though.
> I was just thinking how media works: a ray hits an object, several samples
> along the ray are taken, and the light along the ray is calculated. This
> takes time, but with GHz PCs...
> Just thinking aloud: A ray hits an object (say, a sphere). A second sphere
> which is a little smaller is tested against the same ray. Now I know a
> finite segment of the ray that is inside the "boundary" of the sphere. I'd
> apply a root solver to e.g. the leopard pattern plus the distance to the
> inner sphere along that finite segment (I'm afraid this isn't even close to
> being mathematically correct, I hope you can see what I mean...). So now I
> have the intersection of a sphere with a "leopard" hyper-texture. Of couse
> this is slow, but currently I'm using millions of spheres, which is probably
> slower (at least as soon as windows starts swapping).
Hmm...how is this different from an isosurface? Aside from the more
flexible container.
> Yes, close. Pigments like granite or ripples aren't interpreted either.
> There's one thing isosurfaces can't do: you can't wrap them around a
> height_field.
I think you might be able to warp the height field function in such a
way to do this...maybe. But other objects are more of a problem: meshes,
CSG, julia fractals, etc. Deforming an isosurface is just not the same
thing as deforming a mesh: deforming the surface in a direction parallel
to the normal is easy for spheres or planes, but much harder for other
shapes, and some shapes just can't be represented as an isosurface (you
could probably do some bezier patches, but it would take some very
clever clipping, and won't work for all patches).
> I also think wraping an isosurface around the boundary of a primitive should
> be faster because the boundary is smaller than the whole object, so less
> space has to be tested against some function etc.
So just make a way to specify more complex container shapes. I don't
think they have to be as limited as they are.
I just don't think the concept of a hypertexture applies to anything but
a surface-based rendering engine, using meshes, spline surfaces, etc.
It seems to me that the best alternative for POV is to add tessellation
capability for all objects. Add a general algorithm like marching
tetrahedrons that will work for anything (though you will have to place
limits on it for infinite shapes), and more refined methods for spheres,
cones, etc. (for example, tesselating a triangle is a bit redundant and
the general algorithms often just won't work well)
Then add support for performing complex operations on meshes:
deformations, subdivision, etc. Maybe capability to do subdivision at
render-time, so you don't have to store so many triangles but can stand
the slower rendering (similar to the bezier patch primitive).
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Hypertextures (was: Re: sphere memory)
Date: 6 Sep 2002 15:54:25
Message: <3d7907f1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <chr### [at] netplex aussie org> ,
Christopher James Huff <chr### [at] mac com> wrote:
<snip>
I have to admit I never actually read either the section in the book (I
happen to only have a German shortened and updated version of it at home)
nor the paper. However, if you are interested I can try to remember looking
it up at the university library next time when I have to return books (that
would be on the 19th). I could then scan it and upload a copy somewhere, if
you are interested.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Niki Estner
Subject: Re: Hypertextures (was: Re: sphere memory)
Date: 7 Sep 2002 14:14:29
Message: <3d7a4205@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Hmm...how is this different from an isosurface? Aside from the more
> flexible container.
The difference is: you can design a scene with "basic" objects, render them
fast until you get the right geometry, and then apply a texture to it that
deforms the surface.
Optimizations could be done where a ray is sure to hit the object (only the
normal has to be calculated in that case), and the slow isosurface algorithm
only has to be used at the borders of an object, where you could see the
difference between a faked (normal perturbation) and a real (surface
perturbation) texture.
I just don't have a clue how to do it...
> I think you might be able to warp the height field function in such a
> way to do this...maybe. But other objects are more of a problem: meshes,
> CSG, julia fractals, etc.
Well, I guess the feature I'm thinking of won't work for all kinds of
objects (nothing new: media doesn't work for meshes, for example)
> I just don't think the concept of a hypertexture applies to anything but
> a surface-based rendering engine, using meshes, spline surfaces, etc.
If you told me that media, smooth shadows or radiosity features weren't
possible with a raytracer a few years ago, I' probably have agreed.
I'm just trying to add realism to my images, and a good way to acchieve
realsim for certain scenes is to get rid of that smooth and polished look
raytracing images always used to have. isosurfaces are great, while loops
help a lot and I'd be lost without procedural textures. But I think lots of
things can still be done here.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thomas Willhalm
Subject: Re: Hypertextures (was: Re: sphere memory)
Date: 9 Sep 2002 13:56:47
Message: <3d7ce0de@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Niki Estner wrote:
I did something similiar to hypertextures in the my picture "bear"
(http://www.grafik.willhalm.de/), so perhaps I should comment
on this. I more or less read the paper of Perlin and Hoffert, but didn't
like the idea of numerically finding the gradient. That's why I used the
lighting model of Kajiya and Kay from the same proceedings.
>> Hmm...how is this different from an isosurface? Aside from the more
>> flexible container.
> The difference is: you can design a scene with "basic" objects, render
> them fast until you get the right geometry, and then apply a texture to it
> that deforms the surface.
What prevents you from doing this with isosurfaces? They're not _that_ slow,
if you don't use fancy functions like noise (which would give you
interesting
hypertextures). That's what I did in my picture: Model the geometry with
simple functions and apply the "fur" later. At the moment, I not sure
whether it's really worth the trouble to implement the hypertextures in
POVRay or whether we can stick with isosurfaces.
>> I think you might be able to warp the height field function in such a
>> way to do this...maybe. But other objects are more of a problem: meshes,
>> CSG, julia fractals, etc.
> Well, I guess the feature I'm thinking of won't work for all kinds of
> objects (nothing new: media doesn't work for meshes, for example)
Well, CSG is possible with Christoph Hormann's isocsg library
(http://www-public.tu-bs.de:8080/~y0013390/pov/ic/index.html), but
meshes and fractals might be indeed, mmh.., "difficult".
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |