Hi there,

For the images I am making I need lots of tiny, simple objects: grass, hair,
particle systems can be simulated with these.
Unfortunately, if I have 500,000 spheres or more, main memory seams to be
completely full, and PovRay is constantly swapping during the render (and it
takes about 30 min to get to the first pixel - I didn't even wait for the
second). I got 256 mb of main memory, and I think 500,000 spheres should fit
in there. (of course there are other objects too in the scene, but then,
what's a sphere in bytes?)
I tried to use triangle meshes: these do use less memory, but they take much
longer to render, which is, essentially, the point.
Anyway my idea was to make something like a "sphere mesh": a thing that does
the same as a union of spheres, but with less memory used. I think I need
only 12*8 bytes per sphere (transformation matrix plus translation vector).
My question is: Do you think this is a good idea? If yes, why hasn't anyone
done it before? If not, well, why not?
Has anybody tried anything similar? Any advices? I would just have analyzed
what a union of spheres does (maybe with the debugger) and tried to do the
same with a different memory layout, and without virtual functions...

Niki

Post a reply to this message

On Wed, 28 Aug 2002 10:44:59 +0200, "Niki Estner" <nik### [at] freenetde>
wrote:
> I got 256 mb of main memory, and I think 500,000 spheres should fit
> in there.

I'm sure it fits there and the memory consumption is caused by the complicated
texturing, media, csg, unnecessary object copying or something. Posting source
could help in investigation.

> Anyway my idea was to make something like a "sphere mesh": a thing that does
> the same as a union of spheres, but with less memory used. I think I need
> only 12*8 bytes per sphere (transformation matrix plus translation vector).
> My question is: Do you think this is a good idea? If yes, why hasn't anyone
> done it before? If not, well, why not?

Becouse it would use no less memory than spheres. You can crate one "mesh
sphere" and clone it many times as it is done internally for copied meshes
however every mesh will store pointer to original structure + transformation
while original sphere store only four floats (center + radius) for not
transformed sphere. You have to store texture and other object modifiers the
same way in both 'versions' of sphere.

> Has anybody tried anything similar?

I have tried clone object for large csgs and will try again it probably for
3.5 sources.

ABX

Post a reply to this message

I guess this is the wrong newsgroup then, but if you would like to answer,
I'd be pleased anyway. Otherwise I'd post to the advanced-users group.

Posting the whole scene doesn't make much sense since it contains some
height fields, image maps... Too large to post.

But if I create another scene which contains not much more than:

union {

#declare i=0;

#while (i<500000)

sphere { <i*0.01,i*0.02,i*0.03>, 0.04 scale <0.5,0.6,0.7> rotate
<i,i*2,i*3> }

#declare i=i+1;

#end

pigment { colour Red }

}

memory is full as well. I didn't wait for the parser to finish, but with
100,000 spheres, povray needs about 100 MB of memory! (measured with the
physical memory indicator of the W2K task manager).

Is there something wrong with that code? I thought putting the spheres into
a union was a good idea, so they all share one pigment. Also, the texture is
quite simple, as you can see.

Niki

"Niki Estner" <nik### [at] freenetde> schrieb im Newsbeitrag
news:3d6c8f20@news.povray.org...
> Hi there,
>
> For the images I am making I need lots of tiny, simple objects: grass,
hair,
> particle systems can be simulated with these.
> Unfortunately, if I have 500,000 spheres or more, main memory seams to be
> completely full, and PovRay is constantly swapping during the render (and
it
> takes about 30 min to get to the first pixel - I didn't even wait for the
> second). I got 256 mb of main memory, and I think 500,000 spheres should
fit
> in there. (of course there are other objects too in the scene, but then,
> what's a sphere in bytes?)
> I tried to use triangle meshes: these do use less memory, but they take
much
> longer to render, which is, essentially, the point.
> Anyway my idea was to make something like a "sphere mesh": a thing that
does
> the same as a union of spheres, but with less memory used. I think I need
> only 12*8 bytes per sphere (transformation matrix plus translation
vector).
> My question is: Do you think this is a good idea? If yes, why hasn't
anyone
> done it before? If not, well, why not?
> Has anybody tried anything similar? Any advices? I would just have
analyzed
> what a union of spheres does (maybe with the debugger) and tried to do the
> same with a different memory layout, and without virtual functions...
>
> Niki
>
>

Post a reply to this message

On Thu, 29 Aug 2002 17:51:03 -0400, Niki Estner quoth:

> I guess this is the wrong newsgroup then, but if you would like to
> answer, I'd be pleased anyway. Otherwise I'd post to the advanced-users
> group.
> 
> But if I create another scene which contains not much more than:
> 
> union {
> #declare i=0;
> #while (i<500000)
> sphere { <i*0.01,i*0.02,i*0.03>, 0.04 scale <0.5,0.6,0.7> rotate
> <i,i*2,i*3> }
> #declare i=i+1;
> #end
> pigment { colour Red }
>
> memory is full as well. I didn't wait for the parser to finish, but with
> 100,000 spheres, povray needs about 100 MB of memory! (measured with the
> physical memory indicator of the W2K task manager).

This definitely needs looking into: a quick run of the above scene shows

>> Peak memory used:        359841866 bytes

or about 720 bytes per sphere.  If I texture the spheres individually and
remove the union{}, things get even worse:

>> Peak memory used:        621841342 bytes

-- 
Mark

Post a reply to this message

On Fri, 30 Aug 2002 01:21:32 -0400, Mark Wagner <mar### [at] gtenet> wrote:
> or about 720 bytes per sphere.

whole sphere structure in discussed example cause at least:
- 11 pointers
- 1 int
- 1 unsigned long
- 7 single float
- 34 double float

and it contains:
- pointer to sphere and pointers to local structures
- transformation
- center and radius
- bounding box vectors
- other parameters

I don't know how much of memory use vista buffer.
I don't know how much of memory use other structures required for rendering.

ABX

Post a reply to this message

Mark & Niki,
I am sure some of the developers better know the numbers, but if you are willing
to listen to a relative newbie, here is how I see it.

I believe Pov-Ray uses a 4 by 4 matrix of doubles internally for each transform
of anything.  This would account for 16 x 16 = 256 bytes of what you see for
each sphere.  Guessing a little, but automatic bounds,  the light buffers and
vista buffers for half a million objects has to be pushing 256 bytes per object
- this you could actually test by turning these options off. If you try it, I
would not bother completing the render as the performance will be awful.  Just
those things  get us to 512 bytes per sphere.  Then we have the sphere itself at
4 x 16 = 64 bytes.  Probably at least 4 pointers at 4 bytes is another 16 bytes
a sphere. Let see that gets us to 592 bytes per sphere. Just to store the
calculated image for say an 800 x 600 render (Internally 3 x 16 bytes a pixel)
is about 46 bytes per sphere and there is bound to be pointers from each of
those screen locations to something for another 4 bytes per sphere.  That gets
us to 642 bytes a sphere.  I myself cannot account for the remaining 80 bytes
per sphere, but I would make a bet there are people here who know.

Mark, I think the doubling you saw when you individually textured is simply
because instead of storing one texture for all spheres you must now  store
500,000 and these texture structures. Even when textures are very, basic they
are not small and each will most probably be themselves transformed which means
pointers at the very least.

I guess I don't see this amount of storage as being that out of line - if
performance and reasonable accuracy are you goals.  I expect it is possible to
more compactly represent this data, but likely only at some performance expense
and code complexity.  Someone, in one of the Pov-Ray news groups, mentioned the
idea of an option to use floats everywhere instead of doubles to reduce storage.
Pov-Ray would run this way, but I doubt you would like the inaccuracies which
would be apparent in all but the simplest images.

Memory is reasonably priced these days - perhaps Pov-Ray costs something after
all! :-)
Bill P.

Post a reply to this message

On Fri, 30 Aug 2002 03:29:33 -0400, "William F. Pokorny"
<pok### [at] attglobalnet> 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.

ABX

Post a reply to this message

This question may be dumb, but why does a sphere need a bounding box? It
isn't used during rendering, is it?
Also, why does an ellipsoid need a center and a readius? The light ray must
be transformed into "sphere space"
anyway, couldn't center and radius be done right with that, too
(scale+translate of unity sphere)? If I say all my spheres share one
texture, couldn't I save some of the pointers for texture, interior,...?
That was basically the idea when I started to think about my "sphere_mesh".
I began to implement it, it needs one transformation per sphere (as already
said, 2x4x4x8 bytes). Unfortunately, my spheres don't use e
vista/light-buffer anymore of course, which makes them quite slow. I read
(in the vlbuffer comments) that the triangle-mesh and blob objects have
their own "vista-buffering-like" optimizations. Both objects are too slow
for me, but I'll take a deep look at the mesh-bounding-trees, I guess.
Now, finally, the last dumb question: All matrices are 4x4, while only 4x3
is needed (3x3 transformation matrix plus 3x1 translation vector). Couldn't
I store the matrices in 4x3 format, "unpacking" them when needed (64 bytes
per sphere)? Also, I could try to store the matrix with floats instead of
doubles (another 96 bytes).

All this doesn't make nice code, and it's no fun doing it anyway, so if
anyone got any better ideas for me, please tell me so.

Niki

"ABX" <abx### [at] abxartpl> schrieb im Newsbeitrag
news:uf3umuo52v40rumoc9smuvfnhr3lfim85r@4ax.com...
> On Fri, 30 Aug 2002 01:21:32 -0400, Mark Wagner <mar### [at] gtenet>
wrote:
> > or about 720 bytes per sphere.
>
> whole sphere structure in discussed example cause at least:
> - 11 pointers
> - 1 int
> - 1 unsigned long
> - 7 single float
> - 34 double float
>
> and it contains:
> - pointer to sphere and pointers to local structures
> - transformation
> - center and radius
> - bounding box vectors
> - other parameters
>
> I don't know how much of memory use vista buffer.
> I don't know how much of memory use other structures required for
rendering.
>
> ABX

Post a reply to this message

On Fri, 30 Aug 2002 10:10:24 +0200, "Niki Estner" <nik### [at] freenetde>
wrote:
> This question may be dumb, but why does a sphere need a bounding box? It
> isn't used during rendering, is it?

Bounding boxes usually are not used in theirs parent objects. They are for
vista buffer for example.

> Also, why does an ellipsoid need a center and a readius? The light ray must
> be transformed into "sphere space"
> anyway, couldn't center and radius be done right with that, too
> (scale+translate of unity sphere)?

It would be much slower.

> If I say all my spheres share one
> texture, couldn't I save some of the pointers for texture, interior,...?

IIRC it is done similiar way, but I can be wrong

> All this doesn't make nice code, and it's no fun doing it anyway, so if
> anyone got any better ideas for me, please tell me so.

Buy RAM ? :-)

ABX

Post a reply to this message

> > [using a matrix transformation instead of center/radius]
> It would be much slower.
For a sphere, I understand this, but for an ellipsoid? The ray has to be
multiplied with a matrix anyway, the center/radius scale/translate matrix
could be combined with the matrix that's already there (that made an
ellipsoid out of the sphere). Wouldn't that save a vector-subtraction (no
big time saving, but not slower at least)

> IIRC it is done similiar way, but I can be wrong
What's IIRC?

> Buy RAM ? :-)
Guess I'll gonna do that...
But admit it: when you read my problem first, you also thought: 500,000
spheres - no problem with 256MB.

Post a reply to this message

On Fri, 30 Aug 2002 11:46:17 +0200, "Niki Estner" <nik### [at] freenetde>
wrote:
> For a sphere, I understand this, but for an ellipsoid? The ray has to be
> multiplied with a matrix anyway, the center/radius scale/translate matrix
> could be combined with the matrix that's already there (that made an
> ellipsoid out of the sphere). Wouldn't that save a vector-subtraction (no
> big time saving, but not slower at least)

That's the problem of design. It would be necessary to add ellipsoid object to
SDL to add this optimization and leave speed of 'normal' sphere. Try this with
own patch.

> > IIRC it is done similiar way, but I can be wrong
> What's IIRC?

http://www.acronymfinder.com

> > Buy RAM ? :-)
> Guess I'll gonna do that...
> But admit it: when you read my problem first, you also thought: 500,000
> spheres - no problem with 256MB.

That's becouse recent time when I watched my 8000x8000 render it was started
with 2GB of RAM ;-)

ABX

Post a reply to this message

> That's the problem of design. It would be necessary to add ellipsoid
object to
> SDL to add this optimization and leave speed of 'normal' sphere. Try this
with
> own patch.

IIRC the ellipsoid is already some kind of an own object type - it has
different methods from the sphere. Making the memory layout different
wouldn't change too much. However, that's just 32 bytes of about 500-1000
bytes per sphere, so that won't solve my problem. The texture pointers and
stuff are in the standard OBJECT_FIELDS, so kicking them I would loose the
vista/light buffer - which again hurts performance badly (indeed, I tried
that already).

Ok, now this is really off-topic, but did anyone ever think about
hyper-textures? I read about it in theory some time ago, but I don't really
have an idea about where to start.
I guess modifying the isosurface object, so it wraps around a given object
(spheres, boxes, cylinders, heightfields come right to my mind), and
limiting it so some optimizations can be done to it, while keeping it
general enough for most effects (hair, grass, wool, cloth, stones, sand,
broken wood, etc).
Unfortunately my imagination doesn't seem to be sufficient for such a
modification, not even mentioning my math...

Post a reply to this message

In article <3d6f4fa4@news.povray.org>,
 "Niki Estner" <nik### [at] freenetde> wrote:

> Ok, now this is really off-topic, but did anyone ever think about
> hyper-textures? I read about it in theory some time ago, but I don't really
> have an idea about where to start.

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. The former has 
problems like high memory use and triangle artifacts, the latter would 
just barely be possible by approximating the curved ray with many short 
straight ray segments, and would be very slow and still limited.
Giving a way to tesselate shapes into meshes and a way to deform meshes 
might be sufficient.


> I guess modifying the isosurface object, so it wraps around a given object
> (spheres, boxes, cylinders, heightfields come right to my mind), and
> limiting it so some optimizations can be done to it, while keeping it
> general enough for most effects (hair, grass, wool, cloth, stones, sand,
> broken wood, etc).

I'm not really sure what you mean, or that you understand isosurfaces. 
There are existing functions for the shapes you listed, but not every 
primitive POV supports can be done as an isosurface. You can't just wrap 
an isosurface around another object, you can usually design the function 
to make a similar surface though. 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?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  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.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3d75ef48@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> 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?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> In article <3d75ef48@news.povray.org>,
>  "Thorsten Froehlich" <tho### [at] trfde> 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

In article <3D76AF80.A953620E@pacbell.net>, Ken <tyl### [at] pacbellnet> 
wrote:

> http://mrl.nyu.edu/~perlin/doc/hypertexture/  ?

Thanks...I should have expected that response, I guess. ;-)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote...
> On Fri, 30 Aug 2002 03:29:33 -0400, "William F. Pokorny"
> <pok### [at] attglobalnet> 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

In article <3d76d3c3$1@news.povray.org> , "Nathan Kopp" 
<pov### [at] nkoppmailshellcom> 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] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> 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

On Thu, 5 Sep 2002 16:49:26 +0200, "Niki Estner" <nik### [at] freenetde>
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

In article <3d777099@news.povray.org>,
 "Niki Estner" <nik### [at] freenetde> 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] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  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] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> 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

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