 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(see images in povray.binary.images)
This little test shows how it is theoretically possible to do non-linear
transformations on objects using megapov.
The object is the union of a cube, a sphere and a cone.
A function based on the distance to this object is created, using the
proximity pattern.
Then an isosurface is created, using this function and a limit slightly
positive. This way, the surface is "just a bit" envelopping the object.
The advantage is that there is no equation here to describe the object;
the proximity pattern does all the job.
The second picture makes use of this first function, which is composed
with a (rather uninteresting) space transform, to perform the reverse
transformation to the object. And the nice point is that this
transformation is non-linear.
The sad point is that the rendering times are absolutely insane.
As Chris wrote, there is a granularity issue here, and very strong
sampling for the proximity detection, high accuracy for the isosurface,
and a bit of AA are necessary to get a fairly ugly and tiny image of a
very simple object.
"Material" questions could certainly be solved the same way to get the
texture follow the object transformation.
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Dispot wrote:
>The sad point is that the rendering times are absolutely insane.
>As Chris wrote, there is a granularity issue here, and very strong
>sampling for the proximity detection, high accuracy for the isosurface,
>and a bit of AA are necessary to get a fairly ugly and tiny image of a
>very simple object.
Could you use the object pattern here and use it as a function?
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> Could you use the object pattern here and use it as a function?
I don't think so.
The object pattern gives only two possible values and I'm not sure the
isosurface algorithm would appreciate. Eg. if the function returns 0
outside and 1 inside, a threshold of 0 would probably give the whole
container, .5 would give nothing and 1 would give "something" inside the
object. This is why I used the proximity pattern with a very small
treshold.
Anyway I'll give it a try.
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <8F8EF73D6seed7@204.213.191.228>, ing### [at] home nl (ingo)
wrote:
> Could you use the object pattern here and use it as a function?
The isosurface uses the gradient of the function in it's calculations,
the object pattern returns one of 2 values, so it basically has an
infinite gradient. This causes the isosurface algorithm problems, it
can't easily find the surface and you end up with a bunch of artifacts.
The same problem will occur with other patterns like checker and with
color_maps with sharp changes in color.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3995C000.235C4553@club-internet.fr>, Francois Dispot
<woz### [at] club-internetfr> wrote:
> The advantage is that there is no equation here to describe the object;
> the proximity pattern does all the job.
Actually, one of my planned enhancements to the proximity pattern
consists of adding a proximity function to some of the shapes...objects
which can't be computed this way, like some CSG's, would still use the
sample method, but objects like spheres and boxes would use their own
equations. Of course, all this would be hidden from the user...
> The sad point is that the rendering times are absolutely insane.
> As Chris wrote, there is a granularity issue here, and very strong
> sampling for the proximity detection, high accuracy for the isosurface,
> and a bit of AA are necessary to get a fairly ugly and tiny image of a
> very simple object.
The above enhancement wouldn't only speed up the pattern, it would also
give perfectly smooth results for some objects. :-)
And of course, blobs don't need this...just use the blob pattern.
> "Material" questions could certainly be solved the same way to get the
> texture follow the object transformation.
I don't understand what you mean...
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <3995C000.235C4553@club-internet.fr>, Francois Dispot
> <woz### [at] club-internetfr> wrote:
>
> > The advantage is that there is no equation here to describe the object;
> > the proximity pattern does all the job.
>
> Actually, one of my planned enhancements to the proximity pattern
> consists of adding a proximity function to some of the shapes...objects
> which can't be computed this way, like some CSG's, would still use the
> sample method, but objects like spheres and boxes would use their own
> equations. Of course, all this would be hidden from the user...
I have already thought about this for meshes and it should be fast to
get the distance from a point to a mesh. Knowing whether it is inside or
not is a different problem...
> > The sad point is that the rendering times are absolutely insane.
> > As Chris wrote, there is a granularity issue here, and very strong
> > sampling for the proximity detection, high accuracy for the isosurface,
> > and a bit of AA are necessary to get a fairly ugly and tiny image of a
> > very simple object.
> > "Material" questions could certainly be solved the same way to get the
> > texture follow the object transformation.
>
> I don't understand what you mean...
If you apply a texture to the above object, you will do so after its
shape is transformed. Thus it is not transformed. If you want to bend a
wooden object, you need to bend the wood pigment the same way you bend
the shape. Here it has not been done (well, the plain white pigment is
quite versatile ;-)
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Dispot wrote:
>
> (see images in povray.binary.images)
>
> This little test shows how it is theoretically possible to do non-linear
> transformations on objects using megapov.
>
[...]
Don't know, whether this has been discussed before, but how about not
transforming the objects but distorting space itself ? That would probably
involve some elementary changes in the raytracing engine itself and can be very
time consuming with complicated transformations. Furthermore it would affect
all objects in the scene equally, which would be something quite different.
I don't really know if this idea is realizable (i never looked at that part of
the Pov source btw. :-)
IIRC there are some efforts including relativistic effects in raytracing
programs which seems somehow similar to my idea (the influence of gravity fields
on light for example)
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39966CA6.84396041@club-internet.fr>, Francois Dispot
<woz### [at] club-internetfr> wrote:
> I have already thought about this for meshes and it should be fast to
> get the distance from a point to a mesh. Knowing whether it is inside or
> not is a different problem...
Actually, that one has already been solved in MegaPOV, all that is left
is the proximity calculation.
> > I don't understand what you mean...
>
> If you apply a texture to the above object, you will do so after its
> shape is transformed. Thus it is not transformed. If you want to bend a
> wooden object, you need to bend the wood pigment the same way you bend
> the shape. Here it has not been done (well, the plain white pigment is
> quite versatile ;-)
Yeah, I understood the problem, but I didn't understand your solution to
it. You said:
> "Material" questions could certainly be solved the same way to get
> the texture follow the object transformation.
But I don't see how they could be solved in the same, or any similar
way, unless you transformed the function by converting it to a pigment
and warping it(so you could just warp the texture in the same way).
Some of what has been called displacement is just modifying the
function...for example, adding noise3d() to the radius of a sphere. This
isn't a displacement, that would be modifying the coordinates given to
the sphere function, like multiplying the coordinates given to the
sphere function by noise3d(), and isn't always as easy to control.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Don't know, whether this has been discussed before, but how about
> not transforming the objects but distorting space itself ? . . .
It could be fun to make scenes in hyperbolic or elliptic space,
but I suspect that'll never be an option in an official version!
--
Anton Sherwood -- br0### [at] p0b0xcom -- http://ogre.nu/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 13 Aug 2000 11:10:22 -0500, Chris Huff wrote:
>In article <39966CA6.84396041@club-internet.fr>, Francois Dispot
><woz### [at] club-internetfr> wrote:
>
>> I have already thought about this for meshes and it should be fast to
>> get the distance from a point to a mesh. Knowing whether it is inside or
>> not is a different problem...
>
>Actually, that one has already been solved in MegaPOV, all that is left
>is the proximity calculation.
But it's not really solved; the method used is a little fiddly.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
