 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You can do non-linear transformations for textures, they are called
warps in POV. Like the black hole warp, turbulence, etc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <Chr### [at] compuserve com> wrote:
: You can do non-linear transformations for textures, they are called
: warps in POV. Like the black hole warp, turbulence, etc.
That's not the same thing. The texture calculations are not raytracing.
You don't trace rays to calculate the texture. You just have a function.
You give that function a 3D-coordinate and it returns a color value. No
raytracing done. For example, a gradient x texture would something like
f(x,y,z) = x
You can invent more complicated functions for more complicated textures.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> That's why we got's blobs :)
<grin> Maybe I should have used a box or a complex CSG as an example then. :{)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
> Non-linear transformations are not possible in raytracing.
<snip>
> .....(it) is not possible for mathematical objects. It is possible
> for meshes since you always can change the coordinates of the vertices, but
> for mathematical objects it simply is not possible (or too difficult to be
> achieved).
> If you want mesh-based objects, you can always model them with a modeller.
> Then you can apply any transformation you want to them.
<smile> Ahh well. I never said it "could" happen. Just said it'd be nice to
have. :{)
I guess I'll just add this to my 'Beam me up Scotty!" list of things I'd love to
see in RL but just aren't feasible... for now...
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, that was the point I was trying(and failing miserably) to make. Oh,
well, I guess I just have to learn to explain things more in my
messages. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, if you have the equation for the shape and a basic knowledge of
mathematics, you could use the isosurface object.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> Well, if you have the equation for the shape and a basic knowledge of
> mathematics, you could use the isosurface object.
<smile> There's one of the walls in my abilities with POV. It'salso
probably why I haven't found the time to download the superpatch and play
with things like isosurfaces. It's been a long, long time since school
and math was never my best subject. :{P
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, a control over scale AND translation (rotation also) would be
great this way. From the beginning of my use of 3D modellors I had
thought this would be a good idea. The problem is the implementation;
a simple sphere, box, cone and so forth is one thing, but a CSG of
them? I think because of a need for a general centering and the lack
thereof with individual primitives as part of a CSG would prevent it's
achievability. (hope I'm wrong... hope I'm wrong...)
Bob
David Heys <cel### [at] hotmailcom> wrote in message
news:37B8347D.345FD1BD@hotmail.com...
> Ken wrote:
>
> > That's why we got's blobs :)
>
> <grin> Maybe I should have used a box or a complex CSG as an example
then. :{)
>
> David
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 16 Aug 1999 09:17:30 -0800, David Heys <cel### [at] hotmailcom>
wrote:
>It'salso
>probably why I haven't found the time to download the superpatch and play
>with things like isosurfaces. It's been a long, long time since school
>and math was never my best subject. :{P
Ah, but the Superpatch contains so much more in addition to isosurfaces:
Sphere sweeps, variable and blurred reflection, and much more. If you can
translate objects and specify a reflection value in the official POV-Ray,
then you should have no problems using the features I've mentioned.
--
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> Yes, that was the point I was trying(and failing miserably) to make. Oh,
> well, I guess I just have to learn to explain things more in my
> messages. :-)
To clarify the problem with non-linear transforms for everyone:
To transform an object, you can do one of the following:
1) transform the object itself (move a sphere's center, change
a sphere's radius, move the vertices of a mesh, etc.)
2) do an INVERSE-transform on the ray that is supposed to hit
the object
Ray-tracer's generally use (2) for to allow intersection with a wide
variety of objects. Using option (1) usually only works well with
certain objects. For example, while scale, rotate, and translate are all
easy with a sphere, it's difficult to apply a rotation directly to a
cube. This proble can be overcome by converting the object to a mesh
format (or using some kind of patch with control points, like a bezier),
but this is generally not desired by the POV-Ray community.
So the problem with non-linear transforms is that you need to (1) be able
to easily get the inverse transformation, and (2) be able to intersect
this result with the object. Let's say you have a ray (a line) and you
transform it with a linear transform (an inverse linear transform is
still linear). After the transformation, the ray will still be
straight (that's what "linear transformation" means: lines stay lines).
But what happens if you transform that ray with a non-linear transform?
It's not straight anymore! Now how do you intersect this new curvy ray
with the object? Ray-marching (as Nieminen pointed out) is basically
the only solution. Other solutions (directly solving the ray-intersection
equation) are limited in the objects that they work with and require lots
of very complicated math.
So, then, why do non-linear transformations work with textures? Well,
with textures, you're just transforming points.... not lines. Points
stay points whether the transformation is linear or not. It doesn't
matter. So you take a point, run it through the inverse transform,
and use the resulting point to determine the texture. Easy for points
(textures), difficult for rays (object intersection).
I hope this clarifies things.
As mentioned before, non-linear transforms could be added, but they
would have to apply the transforms in the forward direction directly
to the objects, which would probably require the objects to be
converted to some sort of mesh first.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
