 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hmm.. odd thought. You know what would be interesting to have in POV? A
scale_map function definable in the X, Y, or Z direction, that you could
use on objects from spheres, to CSG's, to isosurfaces. I'm talking about
being able to do this without having to revert to converting to meshes
of triangles.
ie:
sphere {0,1
pigment {rgb <1,0,0>}
finish {specular 0.3 roughness 0.03}
scale_map y {
[0.0 <1.00, 1.00>]
[0.3 <3.50, 0.75>]
[0.7 <0.50, 2.12>]
[1.0 <1.00, 1.00>]
}
}
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh! Are you talking about something that would allow you to scale say, just
the top portion of a sphere and not the bottom?
Samuel Benge
David Heys wrote:
> hmm.. odd thought. You know what would be interesting to have in POV? A
> scale_map function definable in the X, Y, or Z direction, that you could
> use on objects from spheres, to CSG's, to isosurfaces. I'm talking about
> being able to do this without having to revert to converting to meshes
> of triangles.
>
> ie:
>
> sphere {0,1
> pigment {rgb <1,0,0>}
> finish {specular 0.3 roughness 0.03}
> scale_map y {
> [0.0 <1.00, 1.00>]
> [0.3 <3.50, 0.75>]
> [0.7 <0.50, 2.12>]
> [1.0 <1.00, 1.00>]
> }
> }
>
> David
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SamuelT. wrote:
> Oh! Are you talking about something that would allow you to scale say, just
> the top portion of a sphere and not the bottom?
Yea, but moreso for more complex transformations. I know that a lot can be done
with CSG, but I was thinking of something more along the lines of the
following:
http://www.sinbad.net/~autumn/images/odd_sphere.jpg
This was done in Rhino and exported to POV. The rough equivilant in POV (if we
had this feature) would be:
sphere {0,18
scale_map y{
[0.0 <1.0, 1.0>]
[2/36 <5.5/8, 6.5/8>]
[7/36 <5.5/14, 7/14>]
[14/36 <14.5/17.5, 13/17.5>]
[18/36 <16.5/18, 19.5/18>]
[22/36 <15.5/17.5, 23/17.5>]
[29/36 <8/14, 12/14>]
[34/36 <6/8, 7/8>]
[1.0 <1.0, 1.0>]
}
}
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Heys wrote:
>
> SamuelT. wrote:
>
> > Oh! Are you talking about something that would allow you to scale say, just
> > the top portion of a sphere and not the bottom?
>
> Yea, but moreso for more complex transformations. I know that a lot can be done
> with CSG, but I was thinking of something more along the lines of the
> following:
>
> http://www.sinbad.net/~autumn/images/odd_sphere.jpg
That's why we got's blobs :)
--
Ken Tyler
See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Non-linear transformations are not possible in raytracing.
Ok, that's not quite right. There are two ways to do non-linear
transformations:
1) Instead of calculating just one straight line from the camera and
for an intersection point to the light sources, split the ray into many
little pieces and calculate them separately. You can then vary each sub-line
a little from the previous.
2) Transform the object non-linearly.
The first method would be prohibitively slow. If you, for example,
subdivide the ray in 100 segments, that's the same as having 99 transparent
planes in front of the camera and max_trace_level set to 100. And this not
only for the camera rays, but also for shadow rays! (And virtually every
ray traced; reflection, refraction, radiosity...) Just imagine that your
shadow calculations would be 100 times slower than now (currently only
1 ray is needed for shadows, even if there are semitransparent objects in
the way).
The second method 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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
