 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was searching for a possibility to do mipmapping in POV-Ray.
This one uses 11 different images (scaled
800*800,400*400,200*200,100*100,50*50,25*25,12*12,6*6,3*3,2*2 and 1*1
pixels) and interpolates between them in function of the distance from
the camera and the angle of the surface (using an average between a
spherical pattern and the aoi-pattern.
The scale of the spherical pattern is very resolution-dependant (a
smaller output-image requires a smaller spherical-pattern), and as it is
now it doesn't look good in reflections or refractions though.
Is there a reason that POV-Ray doesn't support it natively ? I believe
the reflection/refraction problem could be solved if I had access to the
length of the ray from the camera to the object (being the sum of the
lengthts of all recursive rays for that pixel... I seem to be having
some trouble expressing myself in English lately :-/ ), and also the
scale of the spherical pattern could be calculated automatically in
function of the output-resolution. Both things (I think) could easily
be coded into POV-Ray (if you know how to program in C, which,
unfortunately, I don't).
cu!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
Attachments:
Download 'mipmap_without.jpg' (104 KB)
Download 'mipmap_with.jpg' (72 KB)
Preview of image 'mipmap_without.jpg'
Preview of image 'mipmap_with.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen <zeg### [at] povplace com> wrote:
> Is there a reason that POV-Ray doesn't support it natively ?
Nobody has made a decent patch for it and there has not been enough
popular demand.
Note that mipmapping will not work correctly with reflection and
refraction from curved surfaces. If a ray has been reflected or
refracted from a curved surface then it's not enough to simply know
the sum of the ray lengths in order to choose the proper mipmap.
What is needed to know is probably way too complicated to calculate
for it to be worth the trouble.
OTOH, mipmapping can only add to the quality of the rendering.
It will most probably not make any image look worse than what POV-Ray
currently generates (when using image maps).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well really what you'd want is anisotropic filtering. Take the 4 texture
coordinates of 4 pixel centers and compute the true average of the texture
within that quadrilateral region (though even a quadrilateral is an
approximation). Obviously with pov's internal patterns a true average won't
always be possible but you could adaptively sample the texture within that
area far faster than you can adaptively anti-alias the image to get a
similar quality result.
Mip maps save you from needing so many samples, but they also effectively
bleed in colours from outside the sample area.
--
Tek
http://evilsuperbrain.com
"Zeger Knaepen" <zeg### [at] povplacecom> wrote in message
news:438f9dee@news.povray.org...
I was searching for a possibility to do mipmapping in POV-Ray.
This one uses 11 different images (scaled
800*800,400*400,200*200,100*100,50*50,25*25,12*12,6*6,3*3,2*2 and 1*1
pixels) and interpolates between them in function of the distance from the
camera and the angle of the surface (using an average between a spherical
pattern and the aoi-pattern.
The scale of the spherical pattern is very resolution-dependant (a smaller
output-image requires a smaller spherical-pattern), and as it is now it
doesn't look good in reflections or refractions though.
Is there a reason that POV-Ray doesn't support it natively ? I believe the
reflection/refraction problem could be solved if I had access to the length
of the ray from the camera to the object (being the sum of the lengthts of
all recursive rays for that pixel... I seem to be having some trouble
expressing myself in English lately :-/ ), and also the scale of the
spherical pattern could be calculated automatically in function of the
output-resolution. Both things (I think) could easily be coded into POV-Ray
(if you know how to program in C, which, unfortunately, I don't).
cu!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Nobody has made a decent patch for it and there has not been enough
> popular demand.
>
> Note that mipmapping will not work correctly with reflection and
> refraction from curved surfaces.
And non-perspective cameras and shadows and non-linearly transformed
(warped) images and all uses of images outside textures.
It is fair to say the concept of mip-mapping is essentially incompatible
with raytracing although with a lot of work it could be possible to
bridge this incompatibility of course.
> OTOH, mipmapping can only add to the quality of the rendering.
> It will most probably not make any image look worse than what POV-Ray
> currently generates (when using image maps).
It will look worse in all cases the algorithm chooses a lower resolution
map than it should.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:dmp4nm$jk9$1@chho.imagico.de...
> Warp wrote:
> > Nobody has made a decent patch for it and there has not been
enough
> > popular demand.
> >
> > Note that mipmapping will not work correctly with reflection and
> > refraction from curved surfaces.
>
> And non-perspective cameras and shadows and non-linearly transformed
> (warped) images and all uses of images outside textures.
shadows of transparent image_maps you mean?
ok, so don't use mipmapping in those cases. After some google'ing, I
noticed that you seem to have something almost irrational against the
implementation of mipmapping. OK, it won't work in all cases, but it
will work in some very frequently used case, which (imho) makes it very
interesting and worth implementing.
> It is fair to say the concept of mip-mapping is essentially
incompatible
> with raytracing although with a lot of work it could be possible to
> bridge this incompatibility of course.
I disagree. I would say: it's fair to say the concept of mip-mapping is
essentially incompatible with some aspects of raytracing.
> > OTOH, mipmapping can only add to the quality of the rendering.
> > It will most probably not make any image look worse than what
POV-Ray
> > currently generates (when using image maps).
>
> It will look worse in all cases the algorithm chooses a lower
resolution
> map than it should.
then one has to make sure the algorithm doesn't choose a lower
resolution map than it should, and of course make it optionally.
cu!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen wrote:
>
>>It is fair to say the concept of mip-mapping is essentially incompatible
>>with raytracing although with a lot of work it could be possible to
>>bridge this incompatibility of course.
>
>
> I disagree.
I don't care. If you think you know better - fine, go ahead an
implement it. But to be frank your disagreement does not seem to be
based on understanding and differing from my assessment but on not
liking the conclusion.
To phrase it again in a way that does not require a technical background
to understand: Implementing a very basic support for the concept of
mip-mapping in a raytracer that can be used in practical applications
would be so much work and would introduce so much bloat to the source
code in form of special case handling and making additional data
available that is not needed or even generated in normal raytracing that
i seriously doubt it will be implemented in POV-Ray.
I also think a well designed implementation of this would be a great
thing to have (not mainly for smooth texturing but because elements of
it could be useful for other purposes as well). But i am simply
realistic about the chances of this happening.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ehhhhhh who's going to implement that imp mapping thing?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>> To phrase it again in a way that does not require a technical background
>> to understand: Implementing a very basic support for the concept of
>> mip-mapping in a raytracer that can be used in practical applications
>> would be so much work and would introduce so much bloat to the source
>> code in form of special case handling and making additional data
>> available that is not needed or even generated in normal raytracing that
>> i seriously doubt it will be implemented in POV-Ray.
Where exactly would that difficulty be? Can you be more specific?
I disagree with that statement.
The only thing that trilinear interpolation would need is to
calculate mipmaps from image maps (when requested), which is
extremely trivial to do (and only needs 1/3 of additional memory),
and at trace time to know the sum of ray lengths so far as well as
the distance between image pixels, which is very trivial too.
Calculating trilinear interpolation from these values is very easy.
"It doesn't work correctly with reflections/refractions from
curved surfaces" is actually not a reason to not to implement those
simple steps I described above. There are tons of images out there
which do not need reflections/refractions to work correctly (or at
all). There are tons of mesh-based imagemapped scenes out there
which would greatly benefit from trilinear interpolation.
If in a certain scene the trilinear interpolation looks annoyingly
bad in a certain reflection or refraction, the interpolation can be
turned off and you'll get what POV-Ray currently renders. What's the
problem? If you don't like it, you are not forced to use it.
(In a more versatile implementation you could turn interpolation
of textures hit by reflected/refracted rays on a per-object basis.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:43922298@news.povray.org...
> Where exactly would that difficulty be? Can you be more specific?
>
> I disagree with that statement.
> The only thing that trilinear interpolation would need is to
> calculate mipmaps from image maps (when requested), which is
> extremely trivial to do (and only needs 1/3 of additional memory),
> and at trace time to know the sum of ray lengths so far as well as
> the distance between image pixels, which is very trivial too.
> Calculating trilinear interpolation from these values is very easy.
>
> "It doesn't work correctly with reflections/refractions from
> curved surfaces" is actually not a reason to not to implement those
> simple steps I described above. There are tons of images out there
> which do not need reflections/refractions to work correctly (or at
> all). There are tons of mesh-based imagemapped scenes out there
> which would greatly benefit from trilinear interpolation.
>
> If in a certain scene the trilinear interpolation looks annoyingly
> bad in a certain reflection or refraction, the interpolation can be
> turned off and you'll get what POV-Ray currently renders. What's the
> problem? If you don't like it, you are not forced to use it.
>
> (In a more versatile implementation you could turn interpolation
> of textures hit by reflected/refracted rays on a per-object basis.)
You think you could do it? I would really like to try, but after taking a look
at the POV-Ray source, I really wouldn't know where to start :(
oh, and on a side note, while you're at it :), could you also implement a
no_refraction keyword and make no_image objects per default visible in
refraction? :)
cu!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
