> 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.

The documentation also states that "[#local] temporarily override any 
identifiers with the same name." IMO a bit more clarification should be 
added there, something along the lines of "...unless the identifier name 
is already in use as a macro name, or the #local statement is in a macro 
definition and the identifier name matches one of the macro parameter 
names.".

> This behavior
> breaks the very concept of local variables and makes "black box" modularization
> impossible.

Exactly, in my relatively simple macro which I doubt very many people 
have tried out yet, two people got different namespace clash related 
errors with #local's I'd used inside the macro. In future I'll make sure 
to make all variable names and parameter names unique (by prefixing with 
my name and/or the macro name etc), at which point I might just as well 
use #declare!

I can't believe more people haven't come across this "feature" in the 
last 5 years.

Post a reply to this message

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, so technically 
speaking I guess it does.

And yes, I can name at least one person who is holding back various 
patches for just that very reason.

Post a reply to this message

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