POV-Ray : Newsgroups : povray.binaries.images : First image posting Server Time
30 Sep 2022 20:57:43 EDT (-0400)
  First image posting (Message 11 to 20 of 41)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: MichaelJF
Subject: Re: First image posting
Date: 1 May 2021 13:57:12
Message: <608d9678$1@news.povray.org>
Am 30.04.2021 um 21:40 schrieb Chris R:
> MichaelJF <fri### [at] t-onlinede> wrote:
>> Am 29.04.2021 um 21:39 schrieb Chris R:
>>> I have been playing around with POV-Ray again after a many-year hiatus.  Here is
>>> my first scene using 3.7.
>>>
>>> Credits where credit is due:
>>> Sunlight and sky is from LightSys macros.
>>> Tree and bush are from Arbaro
>>> Various ropes are from the POV-Library ropes macros
>>>
>>> I use isosurfaces with pigment-pattern perturbation a lot for stone and wood
>>> surfaces.
>>>
>>> About the only rendering feature I didn't try out with this was camera blur.
>>>
>>> Appreciate any comments or suggestions for future improvements.
>>> Very nice image. But you asked for improvement. The blue textures of the
>> shutters are a little bit too blue IMO as are the green textures. And
>> the crackle pattern at the well should be exchanged. You can create a
>> better well with the blockwall macros (search the POV-Object collection).
>>
>> Best regards
>> Michael
> 
> Thanks for the comments!  I didn't have any real-world shutters and doors to
> model the colors, so it isn't surprising they stick out.  I could revert to my
> earlier comments about a fantasy world scene, so the colors are more intense,
> but I could certainly see dulling them to make it look more medieval instead.
> 
> 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.
> 
> 
> 
If you cannot download the blockwall macros from the POV server I can 
provide them here if you want. Obviously you don't live in Germany, 
shutters are very common here.

Best regards
Michael


Post a reply to this message

From: Cousin Ricky
Subject: Re: First image posting
Date: 1 May 2021 22:20:58
Message: <608e0c8a$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: First image posting
Date: 2 May 2021 02:47:28
Message: <608e4b00$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: First image posting
Date: 2 May 2021 08:15:00
Message: <web.608e9704f7d27fe1f9dae3025979125@news.povray.org>
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

From: Thomas de Groot
Subject: Re: First image posting
Date: 3 May 2021 02:36:24
Message: <608f99e8$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: First image posting
Date: 3 May 2021 02:48:11
Message: <608f9cab$1@news.povray.org>
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

From: jr
Subject: Re: First image posting
Date: 3 May 2021 03:25:00
Message: <web.608fa41ff7d27fe79819d986cde94f1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: First image posting
Date: 3 May 2021 04:20:00
Message: <608fb230$1@news.povray.org>
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

From: jr
Subject: Re: First image posting
Date: 3 May 2021 05:15:00
Message: <web.608fbe56f7d27fe79819d986cde94f1@news.povray.org>
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

From: Bald Eagle
Subject: Re: First image posting
Date: 3 May 2021 06:35:00
Message: <web.608fd1a5f7d27fe1f9dae3025979125@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.