 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi! For an animation I've been working on, I've got this snippet of
code. It's meant to act as an engine exhaust glow. However, POV has
been ignoring my RGB settings, and has always had the light at maximum
intensity during clock cycle 0.1 to 0.2. What am I doing wrong?
#switch (clock)
#range (0.1, 0.2)
light_source {
<0, 0, zloc-6.5>,
color rgb <(clock - 0.1)*10, (clock - 0.1)*5, 0>
}
#range (0.2, 0.4)
light_source {
<0, 0, zloc-6.5>,
color rgb <1, 0.5, 0>
}
#break
#end
--
ICQ#66022322
"It's a terrifying thing, isn't it? To live in fear.
That's what it's like to be a slave."
--Rutger Hauer, Bladerunner
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Timothy Groves <gro### [at] yahoo couk> wrote in
news:3D988735.6933BF73@yahoo.co.uk
> #range (0.1, 0.2)
> light_source {
> <0, 0, zloc-6.5>,
> color rgb <(clock - 0.1)*10, (clock - 0.1)*5, 0>
> }
add #break here, syntax is (mostly) :
#range (...) ... #break
#range (...) ... #break
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> add #break here, syntax is (mostly) :
> #range (...) ... #break
> #range (...) ... #break
<off-topic side note>
IMHO this is one place where copying the C syntax was not good.
It's a lot more common that the coder wants each case in a switch block to
be executed alone than to want that the execution continues to the next
case after the current one.
Thus it would make a lot more sense to implicitly assume a #break before
any #case or #range command by default, and have a keyword to tell povray
the contrary (ie. "yes, I really want you to continue with the next case
after this has been executed").
So instead of having a #break keyword, we could have some other keyword
for this purpose (which name could be an interesting issue in itself :) ).
</off-topic side note>
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d99bb63@news.povray.org
> any #case or #range command by default, and have a keyword to tell
> povray the contrary (ie. "yes, I really want you to continue with the
> next case after this has been executed").
> So instead of having a #break keyword, we could have some other
> keyword
> for this purpose (which name could be an interesting issue in itself
> :) ).
maybe :
#switch (...)
#case (...) ...
#case (...) ... #nextCase
#case (...) ...
#end
and to have backward-compatibility :
global_settings { sdl { SwitchNextCase on | off } }
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d99bb63@news.povray.org:
> Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> add #break here, syntax is (mostly) :
>
>> #range (...) ... #break
>> #range (...) ... #break
>
> <off-topic side note>
>
> IMHO this is one place where copying the C syntax was not good.
> It's a lot more common that the coder wants each case in a switch
> block to
> be executed alone than to want that the execution continues to the next
> case after the current one.
> Thus it would make a lot more sense to implicitly assume a #break
> before
> any #case or #range command by default, and have a keyword to tell
> povray the contrary (ie. "yes, I really want you to continue with the
> next case after this has been executed").
> So instead of having a #break keyword, we could have some other
> keyword
> for this purpose (which name could be an interesting issue in itself :)
> ).
>
> </off-topic side note>
#fallthru?
"Fall through" is a common comment in C code to emphasize the voluntary lack
of break. http://www.houghi.org/jargon/fall-through.html
Mmm, it is even in the documentation :-)
Unlikely to happen, as it will break old code.
Perhaps it is a good topic for the FAQ, and perhaps the lack of break trap
should be emphasized in the documentation (or not?).
--
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Philippe Lhoste <Phi### [at] GMXnet> wrote in
news:Xns### [at] 204213191226
> #fallthru?
> "Fall through" is a common comment in C code to emphasize the
> voluntary lack of break.
> http://www.houghi.org/jargon/fall-through.html Mmm, it is even in the
> documentation :-)
> Unlikely to happen, as it will break old code.
so...:
#switch (...)
#case (...) ...
#case (...) ... #allthru
#case (...) ...
#end
global_settings {
sdl {
AssumeFallthru off | on // (deafult is OFF)
// btw... good place maybe to set warning level,
// i.e. I don't like "CSG should have at least 2 objects"
// warning while it is very common when tracign not-finished scene
// and I do NOT want to completly turn off warnings
warnings { NotCompleteCsg off NoPigment off MaxGradient off }
}
}
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
Philippe Lhoste <Phi### [at] GMXnet> wrote:
> #fallthru?
> "Fall through" is a common comment in C code to emphasize the voluntary lack
> of break. http://www.houghi.org/jargon/fall-through.html
> Mmm, it is even in the documentation :-)
I don't like "thru", and it is a bit long. Maybe #next or #continue
(continue is used in C for loops, and isn't any shorter, but at least it
is a complete word)
#carry kind of makes sense, but has other meanings. #nobreak would make
sense. Or maybe #proceed? (blah)
Maybe require either #end or #break for every case, instead of having
one be implied. Only backwards incompatible with potential problem
#switch statements...the only scenes that would have problems are scenes
that might not work right now.
Maybe an entirely different syntax where each condition is specified as
part of one statement, something like:
switch(value)
{
case is 1, is 3, of range 5 to 9:
{
...
}
else {
...
}
}
The basic idea: the "case" keyword opens a new case, the conditions are
separate. Could be less verbose than this, and I'm assuming a language
redesign...
I've been thinking about this kind of thing myself for Sapphire, I don't
really like the C syntax either.
Another thing: a switch constant with constant cases can be optimized to
be much faster than the equivalent nested if-else statements. It is less
flexible though, another conditional might be useful, maybe call it
"select" instead to differentiate it from the switch statement. (I
already know about the select() used in functions, I'm assuming it won't
last much longer)
The main differences from a switch statement would be variables for case
values and the ability to use boolean expressions instead of just
matching values. It should be possible to do it using the switch
keyword, just not doing some optimizations if these features are used,
but I like the idea of having it be a different control structure.
> Unlikely to happen, as it will break old code.
The POV Team has talked about large changes in the language before.
Also, this change wouldn't break a huge number of scenes, and those
would be easy to fix: just remove the #break statements for most #case
statements. Other changes would require quite a bit more reworking.
> Perhaps it is a good topic for the FAQ, and perhaps the lack of break trap
> should be emphasized in the documentation (or not?).
I think this would be a good idea if the break syntax is still used.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in message news:3d99bb63@news.povray.org...
>
> <off-topic side note>
> <snip>
> </off-topic side note>
>
Speaking of cumbersome elements, is there a reason why rotate uses degrees
while other vector operations use radians?
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d9a0d82$1@news.povray.org>, "Shay" <sah### [at] simcopartscom>
wrote:
> Speaking of cumbersome elements, is there a reason why rotate uses degrees
> while other vector operations use radians?
There aren't any vector operations that use radians. The vrotate() and
vaxis_rotate() functions use degrees, none of the others use any kind of
angle unit. Are you thinking of the trig functions?
People usually think of angles in real-world measurements in terms of
degrees, but trig usually uses radians. The inconsistency isn't usually
a problem...geometric problems use degrees, math stuff uses radians. It
is more efficient than using degrees for everything, because the C math
library uses radians, and more convenient than using radians.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in message news:chrishuff-
>
> There aren't any vector operations that use radians. The vrotate() and
> vaxis_rotate() functions use degrees, none of the others use any kind of
> angle unit. Are you thinking of the trig functions?
> People usually think of angles in real-world measurements in terms of
> degrees, but trig usually uses radians. The inconsistency isn't usually
> a problem...geometric problems use degrees, math stuff uses radians. It
> is more efficient than using degrees for everything, because the C math
> library uses radians, and more convenient than using radians.
>
It's pretty obvious that my programming vocabulary just wasn't sufficient
for that question! Yes, I was talking about the trig functions. Good guess.
I understand the reasons you posted, but I find the extra steps when using
both trig and rotate functions to be unattractive. I guess if my trig were a
little better, I could eliminate the use of rotate and effectively rotate
vertices with translate. Is there anything like a radrotate() function coded
internally into Pov-Ray?
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
