|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-04-30 3:40 PM (-4), Chris R wrote:
>
> I am working on a new project with bricks around a lighthouse (cone). I'll look
> into the blockwall macros for that as well. I have had issues getting access to
> the POV-Object collection after the server crash.
I believe the Object Collection is still down. It does not respond to
pings. Chris Cason reported that bringing it back online will take more
time than he can budget right now.
In the meantime, Le Forgeron has mirrored all the modules as of April 2019:
https://github.com/LeForgeron/PovContributions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 01/05/2021 om 13:26 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> Yes, that is certainly true indeed. Try to find the balance.
>> Sometimes/often, stochastic anti-aliasing helps for the grainy distance
>> mess.
>
> Presumably, this is what all this "mip-mapping" business is about. Has anyone
> ever tried to emulate that process, that we know of?
>
Good question. It would be interesting to try indeed. RoundTuits are
needed however!
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> > Presumably, this is what all this "mip-mapping" business is about. Has anyone
> > ever tried to emulate that process, that we know of?
> >
> Good question. It would be interesting to try indeed. RoundTuits are
> needed however!
https://www.youtube.com/watch?v=0flY11lVCwY
He covers this briefly in the first 2 minutes.
Just shooting from the hip here, but it sounds like a functional emulation of
this would be to start with a very large, high-def version of the texture and
then make a few smaller versions. Then just have an array of the filenames and
the texture could probably be automagically sampled at the desired resolution
using a polynomial function like I did in the vortex scene or using a spline
like Ingo is doing.
Maybe there's some kind of MOA (minutes of angle) calculation that initially
gets done to optimally set the different image_map resolutions...?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 02/05/2021 om 14:11 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>>> Presumably, this is what all this "mip-mapping" business is about. Has anyone
>>> ever tried to emulate that process, that we know of?
>>>
>> Good question. It would be interesting to try indeed. RoundTuits are
>> needed however!
>
> https://www.youtube.com/watch?v=0flY11lVCwY
> He covers this briefly in the first 2 minutes.
>
> Just shooting from the hip here, but it sounds like a functional emulation of
> this would be to start with a very large, high-def version of the texture and
> then make a few smaller versions. Then just have an array of the filenames and
> the texture could probably be automagically sampled at the desired resolution
> using a polynomial function like I did in the vortex scene or using a spline
> like Ingo is doing.
>
By default, a factor 2 scaling is used, I understand. That is not
difficult; what is (at least for me) is how to chose the right texture
for each render or location in the scene (for instance the background of
a chequered plane smoothly grading into the foreground). Well, I have an
idea of course, but no time to test it out presently. :-/
> Maybe there's some kind of MOA (minutes of angle) calculation that initially
> gets done to optimally set the different image_map resolutions...?
>
Hmm... possibly. I have no idea at this stage however.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 03/05/2021 om 08:36 schreef Thomas de Groot:
> Op 02/05/2021 om 14:11 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>>> Presumably, this is what all this "mip-mapping" business is about.
>>>> Has anyone
>>>> ever tried to emulate that process, that we know of?
>>>>
>>> Good question. It would be interesting to try indeed. RoundTuits are
>>> needed however!
>>
>> https://www.youtube.com/watch?v=0flY11lVCwY
>> He covers this briefly in the first 2 minutes.
>>
>> Just shooting from the hip here, but it sounds like a functional
>> emulation of
>> this would be to start with a very large, high-def version of the
>> texture and
>> filenames and
>> the texture could probably be automagically sampled at the desired
>> resolution
>> using a polynomial function like I did in the vortex scene or using a
>> spline
>> like Ingo is doing.
>>
> By default, a factor 2 scaling is used, I understand. That is not
> difficult; what is (at least for me) is how to chose the right texture
> for each render or location in the scene (for instance the background of
> a chequered plane smoothly grading into the foreground). Well, I have an
> idea of course, but no time to test it out presently. :-/
>
>> Maybe there's some kind of MOA (minutes of angle) calculation that
>> initially
>> gets done to optimally set the different image_map resolutions...?
>>
> Hmm... possibly. I have no idea at this stage however.
>
And I immediately come back to the matter as I suddenly realise that
this would be a crucial technique for using the same granite textures
(forgive me my present obsession with granites) in close foreground
views and landscape-sized backgrounds. Or wouldn't it? Is mipmapping
only useful with image_maps? The examples I have seen so far are just
that. Could it be applied successfully to traditional POV-Ray textures?
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 03/05/2021 om 08:36 schreef Thomas de Groot:
> > Op 02/05/2021 om 14:11 schreef Bald Eagle:
> >> Thomas de Groot <tho### [at] degrootorg> wrote:
> >>
> >>>> Presumably, this is what all this "mip-mapping" business is about.
> >>>> ...
> ...
> Could it be applied successfully to traditional POV-Ray textures?
no idea but reading yr exchange led me to this Wiki page:
<https://en.wikipedia.org/wiki/Mipmap>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 03/05/2021 om 09:19 schreef jr:
> hi,
>
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 03/05/2021 om 08:36 schreef Thomas de Groot:
>>> Op 02/05/2021 om 14:11 schreef Bald Eagle:
>>>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>>
>>>>>> Presumably, this is what all this "mip-mapping" business is about.
>>>>>> ...
>> ...
>> Could it be applied successfully to traditional POV-Ray textures?
>
> no idea but reading yr exchange led me to this Wiki page:
> <https://en.wikipedia.org/wiki/Mipmap>
>
Thanks, yes, I also found that page indeed :-)
Well, should have done that first of all, but the following (hot)
discussion about mimapping with POV-Ray from 2005 can be found here:
http://news.povray.org/povray.newusers/thread/%3C4282a2e9%40news.povray.org%3E/
I conclude from that, that aa is the ray-tracing answer to mipmapping,
and I guess that my initial suggestion of stochastic aa is the correct one.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 03/05/2021 om 09:19 schreef jr:
> > ...
> I conclude from that [thread], that aa is the ray-tracing answer to mipmapping,
> and I guess that my initial suggestion of stochastic aa is the correct one.
taking the 'El Capitan' cliff face as an example, say I want to render two
images: object near base of, and object some distance from. then I need to
choose a scale for the texture(s)? I think that I (as in "numpty" etc) would
benefit from having some row/col table, in the documentation and or as array, of
all parameters involved ("lambda", "octave", such) by scale/suggested distance
(in POV-units?). (and perhaps a macro which expands to the texture at the given
scale/index) (just thinking aloud :-))
regards, jr.
btw, re "graveyards". had to put on an anorak, even for a cursory read. :-)
found out that what I associate with "granite" really is "dolerite". thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
what is (at least for me) is how to chose the right texture
> for each render or location in the scene (for instance the background of
> a chequered plane smoothly grading into the foreground).
I guess you could have a macro generate the texture, and have an AutoScale
argument. The distance from the camera to the closest object (user-supplied
value) could be used to set the scale. Might need to set a pov unit = real
world measurement ratio and base everything off that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 3-5-2021 om 11:11 schreef jr:
> hi,
>
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 03/05/2021 om 09:19 schreef jr:
>>> ...
>> I conclude from that [thread], that aa is the ray-tracing answer to mipmapping,
>> and I guess that my initial suggestion of stochastic aa is the correct one.
>
> taking the 'El Capitan' cliff face as an example, say I want to render two
> images: object near base of, and object some distance from. then I need to
> choose a scale for the texture(s)? I think that I (as in "numpty" etc) would
> benefit from having some row/col table, in the documentation and or as array, of
> all parameters involved ("lambda", "octave", such) by scale/suggested distance
> (in POV-units?). (and perhaps a macro which expands to the texture at the given
> scale/index) (just thinking aloud :-))
>
Yes, I guess that is the crucial point here. Otoh, It can also be solved
by using a much simpler texture for the background, involving the same
colour_map scaled down, and without all the fancy stuff...
>
> regards, jr.
>
> btw, re "graveyards". had to put on an anorak, even for a cursory read. :-)
> found out that what I associate with "granite" really is "dolerite". thanks.
>
<grin> They are often mixed-up.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |