Am 17.07.2013 04:27, schrieb clipka:
> Am 09.06.2013 15:12, schrieb Christian Froeschlin:
>
>>> (In fact, why aren't coders posting more patches? Is everyone waiting
>>> till 3.7 Final or something?)
>>
>> actually I seem to recall the license / source code comments did not
>> allow the publishing of modified sources for beta versions. Not sure if
>> that also holds for release candidates.
>
> The corresponding text is still in all the file headers

(of RC7, that is)

Post a reply to this message

Am 19.06.2013 16:49, schrieb Thomas de Groot:

>> Bring on mcpov merged into POV 3.7 !! If I had the time I'd definitely
>> give it a shot.
>
> I am too happy with 3.7 for the things I do. ;-)

Believe me, once you get to toy around with blurred reflections you 
/will/ want them integrated in 3.7 :-) It's amazing how much more 
credibility it brings to textures midway between between dull and shiny 
(non-polished metallic surfaces are just the tip of the iceberg in this 
regard).

(You /will/ also want a faster computer of course :-P)

Post a reply to this message

Am 17.06.2013 16:41, schrieb scott:

> The only reason I left the sphere object in there is because in mcpov
> you can't use light_sources, you are forced to model a sun as a very
> bright sphere.

... which is a huge drawback of MCPOV, if I'm asked. The ideal solution 
would be to have the best of both worlds.

Post a reply to this message

Am 10.07.2013 16:43, schrieb Cousin Ricky:
> scott <sco### [at] scottcom> wrote:
>> While we're at it this also causes an error (even if the definition for
>> A is in a different file):
>>
>> #macro A()
>> #end
>> #macro B()
>> #local A=1;
>> #end
>> B()
>>
>> This one is a bit more serious as it means if any macro in your scene
>> uses a local variable with the same name as another macro you'll get an
>> error.
>
> This is a known problem, although I do not know that the POV Team perceives it
> as a problem.  When I brought it up 5 years ago, I was quoted documentation of
> macro names being global in scope, which was just a red herring.  This behavior
> breaks the very concept of local variables and makes "black box" modularization
> impossible.

The current POV-Ray development team (*) does perceive the whole 3.x 
generation SDL parser as one big monolithic problem :-P


(* or "dev team" for short; I guess that's what you mean. There did 
exist some group of people called the "POV Team", but they were focused 
on user support rather than development.)

Post a reply to this message

On 17-7-2013 4:50, clipka wrote:
> Believe me, once you get to toy around with blurred reflections you
> /will/ want them integrated in 3.7 :-) It's amazing how much more
> credibility it brings to textures midway between between dull and shiny
> (non-polished metallic surfaces are just the tip of the iceberg in this
> regard).

Oh, I do understand that indeed. Let's say that I am not too 
demanding... ;-)

>
> (You /will/ also want a faster computer of course :-P)
>
Yeah...

Thomas

Post a reply to this message

>> The only reason I left the sphere object in there is because in mcpov
>> you can't use light_sources, you are forced to model a sun as a very
>> bright sphere.
>
> ... which is a huge drawback of MCPOV, if I'm asked. The ideal solution
> would be to have the best of both worlds.

Indeed - bring it on! :-)

The other obvious drawback is that you need to run multiple instances of 
MCPOV (all started at least 1 second apart as I found out...) to make 
good use of modern CPUs, then merge the images afterwards. I've 
automated this process but it's still not as good as being able to do it 
all in one program and see the results in real time.

Post a reply to this message

Am 17.07.2013 09:52, schrieb scott:
>>> The only reason I left the sphere object in there is because in mcpov
>>> you can't use light_sources, you are forced to model a sun as a very
>>> bright sphere.
>>
>> ... which is a huge drawback of MCPOV, if I'm asked. The ideal solution
>> would be to have the best of both worlds.
>
> Indeed - bring it on! :-)

Guess what: I probably will :-D

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I think I found the culprit: Your original SunPos() is divided by 1000!
>
> Thomas

What line number is that at? I am having the same issue.


Mike

Post a reply to this message

On 8-9-2016 8:56, posfan12 wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I think I found the culprit: Your original SunPos() is divided by 1000!
>>
>> Thomas
>
> What line number is that at? I am having the same issue.
>
>
> Mike
>

Goodness! That was three years ago! ;-)

Without going over the whole discussion again, I guess it is about:

// uncomment the below lines to have a physical sun in the scene with 
realistic brightness
// and size (useful if using mcpov or perhaps radiosity?)
  #local SunRadius = vlength(sp/1000)/214.8;
  sphere{ sp/1000, SunRadius pigment{color rgb 1} finish{emission 1} 
no_shadow}

Forgive me, I do not have the info freshly available in my mind anymore...

-- 
Thomas

Post a reply to this message

>>> I think I found the culprit: Your original SunPos() is divided by 1000!
>>>
>>> Thomas
>>
>> What line number is that at? I am having the same issue.
>>
>>
>> Mike
>>
>
> Goodness! That was three years ago! ;-)
>
> Without going over the whole discussion again, I guess it is about:
>
> // uncomment the below lines to have a physical sun in the scene with
> realistic brightness
> // and size (useful if using mcpov or perhaps radiosity?)
>  #local SunRadius = vlength(sp/1000)/214.8;
>  sphere{ sp/1000, SunRadius pigment{color rgb 1} finish{emission 1}
> no_shadow}
>
> Forgive me, I do not have the info freshly available in my mind anymore...

IIRC I think the consensus was that the 1000 factor (used on both lines) 
should be tweaked to make the sphere seem "far away" in your specific 
scene (but not too far away it causes accuracy issues). I think without 
the /1000 the sun is just too far away for the maths to cope when 
dealing with normal scenes of the order of a few metres.

Post a reply to this message