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