 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A cylindrical light source could be better for a laser.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> A cylindrical light source could be better for a laser.
That's what I said, cylindrical =)
Ooh, you misunderstood my "cylinder lights are really point light sources
with their effect constrained by a cylinder." What I meant by this, is that
internally, POV-Ray takes two steps to see if a point is lit by a
cylindrical light source:
1. check to see if the point is contained within the cylinder that you've
defined for the cylindrical light source.
2. if it is, check to see if there's a straight line from the point to the
light source's origin.
The problem is that all of the rays aren't parallel. Points that are very
close to the light source's position, but still inside the cylinder, might
be lit up unexpectedly because they're being lit *from the center of the
cylinder*, not parallel to the cylinder.
A cylinder light with an infinitely large cylinder behaves identically to a
regular point light source.
This works well enough normally. But when there are photons, I'm not sure
how it behaves, since photons may be reflected. It's no longer able to
perform step number one since the photons are likely to be out of the
cylinder but still legitimate, so if you put a reflective object close to
the light source, it might behave strangely. It's hard to explain what I
mean.
Here's what I mean: if you put a cylindrical light source with radius one at
the origin and shine it at a perfectly transparent plane at z=3 (with no
refraction or reflection), and make it shoot photons at that plane, I think
the other side of the plane will look like there was a point light source at
the origin, and the plane had a dark, shadow-casting pigment everywhere
except for a transparent hole with radius one at x=y=0.
Try that same image you just posted with a cylinder light source and no
actual cylinder object, and see if it still works. It might; I'm not sure.
Move the light real close to the photon reflecting object to see.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Flaming Monarch" <fla### [at] gates com> wrote in message
news:3CE### [at] gatescom...
> other than a cylinder
> one that I can really use like aim it at a spot and have it work like a
> laser
> thanks
IMHO you'd be better of writing macros to handle using cylinders. Any other
approach is presumably going to require scattering media (if you want the lasers
to be visible) and photons (if mirrors are involved), so render times are going
to shoot through the roof.
Now, a nice set of laser-macros that trace a path would be nice - is there a way
to return the reflection component of a surface?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> wrote in message
> IMHO you'd be better of writing macros to handle using cylinders. Any other
> approach is presumably going to require scattering media (if you want the
lasers
> to be visible) and photons (if mirrors are involved), so render times are
going
> to shoot through the roof.
>
> Now, a nice set of laser-macros that trace a path would be nice - is there a
way
> to return the reflection component of a surface?
>
You could calculate if from the normal returned by trace(). . . but you probably
already knew that.
Batronyx ^"^
--
light_source{0,1}#macro c(J,a)sphere{0,1pigment{rgb z}scale a translate J+O}
#end#macro B(R,V,O)c(0,4)intersection{c(V,R)difference{c(-z*4x+10)c(-z*4.1x+
10)c(0<7.5,45,5>)}}#end B(12,0z*25)B(8y*4<0,12,50>) // Batronyx ^"^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think he was referring to the amount of reflection, as
reflection .4 or even in version 3.5 reflection{.2,.7} would
be something far different from 100% mirror-like reflection...
AFAIK it is not possible to return those, unless you use
trace on objects, of which you have set the reflection inside
an array. A macro could trace the object, check the reflection
in the array, and return intersection point, surface normal, and
reflection value.
Batronyx wrote:
> "Tom Melly" <tom### [at] tomandlucouk> wrote in message
> > IMHO you'd be better of writing macros to handle using cylinders. Any other
> > approach is presumably going to require scattering media (if you want the
> lasers
> > to be visible) and photons (if mirrors are involved), so render times are
> going
> > to shoot through the roof.
> >
> > Now, a nice set of laser-macros that trace a path would be nice - is there a
> way
> > to return the reflection component of a surface?
> >
>
> You could calculate if from the normal returned by trace(). . . but you probably
> already knew that.
>
> Batronyx ^"^
>
> --
> light_source{0,1}#macro c(J,a)sphere{0,1pigment{rgb z}scale a translate J+O}
> #end#macro B(R,V,O)c(0,4)intersection{c(V,R)difference{c(-z*4x+10)c(-z*4.1x+
> 10)c(0<7.5,45,5>)}}#end B(12,0z*25)B(8y*4<0,12,50>) // Batronyx ^"^
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3CEC3A25.46062591@gmx.de...
> I think he was referring to the amount of reflection, as
> reflection .4 or even in version 3.5 reflection{.2,.7} would
> be something far different from 100% mirror-like reflection...
>
> AFAIK it is not possible to return those, unless you use
> trace on objects, of which you have set the reflection inside
> an array. A macro could trace the object, check the reflection
> in the array, and return intersection point, surface normal, and
> reflection value.
>
Yeah, that makes more sense upon re-reading. <DOH!> Thanks for setting me
straight.
Let me see if I follow you correctly here; you might not need an array for a
single simple object with an explicit reflection value set in the texture, but
an array would be handy for a union/merge object and/or complex texture mapped
objects right? If so, how might you get the values for variable reflection,
and/or the interpolated values within a pigment_pattern or image_pattern? The
eval_pigment() function in functions.inc ?
Batronyx ^"^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am not really firm in stuff regarding functions. For all
I know, eval_pigment will return you only the rgb-component,
and this wouldn't be slope-dependant. If this is correct, it would
be of no use for the thing we're trying to achieve.
Also, we couldn't do a trace against a union/merge, since we
wouldn't know, which objecs of that union/merge we are
actually hitting. We need to look at the different objects
one by one, check, which is the nearest (first) intersection,
look for the reflection-variables in already mentioned array,
and calculate the actual reflection-values from there.
It in fact we do have a slope-independant pigment, we might
use eval_pigment after all in case we want to calculate the
influence of the color on the reflected laserbeam.
All this together would be one major project, as you need a
very intuitive use of pigments/reflections/arrays for users to
quickly set everything, e.g. by calling macros at the appropriate
places.
Batronyx wrote:
> "Tim Nikias" <tim### [at] gmxde> wrote in message
> news:3CEC3A25.46062591@gmx.de...
> > I think he was referring to the amount of reflection, as
> > reflection .4 or even in version 3.5 reflection{.2,.7} would
> > be something far different from 100% mirror-like reflection...
> >
> > AFAIK it is not possible to return those, unless you use
> > trace on objects, of which you have set the reflection inside
> > an array. A macro could trace the object, check the reflection
> > in the array, and return intersection point, surface normal, and
> > reflection value.
> >
>
> Yeah, that makes more sense upon re-reading. <DOH!> Thanks for setting me
> straight.
>
> Let me see if I follow you correctly here; you might not need an array for a
> single simple object with an explicit reflection value set in the texture, but
> an array would be handy for a union/merge object and/or complex texture mapped
> objects right? If so, how might you get the values for variable reflection,
> and/or the interpolated values within a pigment_pattern or image_pattern? The
> eval_pigment() function in functions.inc ?
>
> Batronyx ^"^
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3CEC73CF.F75C3AC5@gmx.de...
<snip>
Yeh - IMHO it would be a nightmare to implement unless it was possible to return
the reflection component, etc. of a point.
Without this, any scene where you wanted to simulate a laser bouncing around
would require a very complex setup.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Why would a mirror have angle-dependant reflection?
Grim
Tom Melly wrote:
> "Tim Nikias" <tim### [at] gmxde> wrote in message
> news:3CEC73CF.F75C3AC5@gmx.de...
>
> <snip>
>
> Yeh - IMHO it would be a nightmare to implement unless it was
> possible to return the reflection component, etc. of a point.
>
> Without this, any scene where you wanted to simulate a laser bouncing
> around would require a very complex setup.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3CEC73CF.F75C3AC5@gmx.de...
> I am not really firm in stuff regarding functions. For all
> I know, eval_pigment will return you only the rgb-component,
> and this wouldn't be slope-dependant. If this is correct, it would
> be of no use for the thing we're trying to achieve.
Actually, I was thinking of using the .gray value of the function as a mapping
parameter from which to approximate the interpolated values, but even this won't
work if we're talking blended/layered textures, since the color could be off and
skew the results.
>
> Also, we couldn't do a trace against a union/merge, since we
> wouldn't know, which objecs of that union/merge we are
> actually hitting. We need to look at the different objects
> one by one, check, which is the nearest (first) intersection,
> look for the reflection-variables in already mentioned array,
> and calculate the actual reflection-values from there.
I think that might depend on the object, but I have to agree it would be hard to
achieve consistency without the arrays.
> It in fact we do have a slope-independant pigment, we might
> use eval_pigment after all in case we want to calculate the
> influence of the color on the reflected laserbeam.
Can't disagree here either.
>
> All this together would be one major project, as you need a
> very intuitive use of pigments/reflections/arrays for users to
> quickly set everything, e.g. by calling macros at the appropriate
> places.
>
Yep, it could get messy.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
