|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dcbdcab@news.povray.org>, "Wu Yang" <wya### [at] cswrightedu>
wrote:
> Is Depth_Stack->istack->IPoint the (x,y,z) value of a intersection point?
It is one of them, if there are any on the stack. (What else would it
be?)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you for your reply.
I think there are maybe more than or less than one intersection point in the
stack, and they are the intersection points with the same ray, and what I
need is Best_Intersection->IPoint in Trace() function(render.cpp file). Is
it right? Thanks.
Best Regard
Wu Yang
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3dcbdcab@news.povray.org>, "Wu Yang" <wya### [at] cswrightedu>
> wrote:
>
> > Is Depth_Stack->istack->IPoint the (x,y,z) value of a intersection
point?
>
> It is one of them, if there are any on the stack. (What else would it
> be?)
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dcc1ea5@news.povray.org>, "Wu Yang" <wya### [at] cswrightedu>
wrote:
> I think there are maybe more than or less than one intersection point in the
> stack, and they are the intersection points with the same ray, and what I
> need is Best_Intersection->IPoint in Trace() function(render.cpp file). Is
> it right? Thanks.
What you need is to buy and read a good C++ book or take a good course
in C++, and then take the time to actually figure out what the POV-Ray
source code does before trying to make any changes.
If you then have a problem, state the entire problem and your goal
clearly at the very start, not some useless "is it right" garbage that
keeps everyone guessing as to what you are really doing. There really is
a category of "stupid" questions, and most of yours fit in it...you
could most likely easily figure out the answer yourself, if you knew the
language the source code is written in.
And finally, *READ THE REPLIES*. I don't know why some people just
ignore it when people give them the answer, or worse, ignore the answer
and go off on a wild goose chase...
Now: where is Trace() defined? What does that code say it does? It says
nothing about meshes, does it? The Trace() function is called to compute
the color seen along a ray, adding this code there won't catch all
intersection tests, but it will catch any kind of intersection, not just
ones with meshes. I can't tell you how to do it, because you haven't
said *what* you are trying to do, or what your goal is.
--
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:
> There really is
> a category of "stupid" questions, and most of yours fit in it...
There's a saying that says "there are no stupid questions".
Of course this saying has a more figurative meaning than literal meaning.
It means that each person asks questions in the best way they can, according
to their knowledge and experience, and it's important to understand that.
From the point of view of a very experienced person, a question made by
an extremely inexperienced one might sound trivial or even stupid, but one
has to understand who is making the question - a complete newbie - and avoid
feeling sense of superiority and disrespect.
Of course it might be that the person who has a rather big goal for his
experience and is asking these newbie questions does not seem to listen
to even the most benevolent answers, given with the best intentions, and
that may sometimes be very irritating, but still we should continue
understanding the position of such person: Without the necessary experience
he is struggling with the problems he is finding and probably very confused
about everything.
The worst thing we can do in a situation like this is disrespecting this
kind of person. We should try to help in any way we can.
(I know, I have been guilty of this kind of disrespect as well, but I'm
trying to learn my lesson...)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you for your reply.
What I want is all the intersection points hitted firstly by the ray, not
just those with the mesh object. The reason I found it in mesh.cpp is that
the object I designed is only made up by mesh object. Yes, Trace() function
is called to compute the color seen along the ray, but there is a variable
called Best_Intersection and I think this variable is the intersection point
I want.
I really appreciate for all of your replies, your replies are very very
helpful to me. Maybe sometimes I can not express my question very clearly
and make you feel a little boring. Sorry about that. I will try my best to
make my question more clearly. Thanks a lot.
Best Regards
Wu Yang
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3dcc1ea5@news.povray.org>, "Wu Yang" <wya### [at] cswrightedu>
> wrote:
>
> > I think there are maybe more than or less than one intersection point in
the
> > stack, and they are the intersection points with the same ray, and what
I
> > need is Best_Intersection->IPoint in Trace() function(render.cpp file).
Is
> > it right? Thanks.
>
> What you need is to buy and read a good C++ book or take a good course
> in C++, and then take the time to actually figure out what the POV-Ray
> source code does before trying to make any changes.
>
> If you then have a problem, state the entire problem and your goal
> clearly at the very start, not some useless "is it right" garbage that
> keeps everyone guessing as to what you are really doing. There really is
> a category of "stupid" questions, and most of yours fit in it...you
> could most likely easily figure out the answer yourself, if you knew the
> language the source code is written in.
>
> And finally, *READ THE REPLIES*. I don't know why some people just
> ignore it when people give them the answer, or worse, ignore the answer
> and go off on a wild goose chase...
>
> Now: where is Trace() defined? What does that code say it does? It says
> nothing about meshes, does it? The Trace() function is called to compute
> the color seen along a ray, adding this code there won't catch all
> intersection tests, but it will catch any kind of intersection, not just
> ones with meshes. I can't tell you how to do it, because you haven't
> said *what* you are trying to do, or what your goal is.
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dcc6dd1$1@news.povray.org>,
"Wu Yang" <wya### [at] cswrightedu> wrote:
> What I want is all the intersection points hitted firstly by the ray, not
> just those with the mesh object.
By which rays? Every single intersection test ever made by the tracer
while rendering, or just the ones from the camera?
> The reason I found it in mesh.cpp is that the object I designed is
> only made up by mesh object. Yes, Trace() function is called to
> compute the color seen along the ray, but there is a variable called
> Best_Intersection and I think this variable is the intersection point
> I want.
It is the nearest intersection Trace() finds. However, because Trace()
is used to compute the color, there will be intersection tests that do
not reach your code, because they don't call Trace(). I think Trace() is
only used for the primary camera rays, reflected rays, and refracted
rays, not for the trace() language function, shadow rays, or anything
else that needs to trace a ray but doesn't need to compute the color
seen along it. I don't know what you want to do with the data, so I
can't make any better suggestions. If you would just tell us what you
are doing, you would get much better help.
> I really appreciate for all of your replies, your replies are very very
> helpful to me. Maybe sometimes I can not express my question very clearly
> and make you feel a little boring. Sorry about that. I will try my best to
> make my question more clearly. Thanks a lot.
Boring isn't the right term, "frustrating" is better. Trying to figure
out what you want from vaguely worded questions and trying to understand
why you are modifying these odd places in the code, especially when you
ignore repeated questions about what you are trying to do.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you for your reply.
I want to compute the distance between the camera and the intersection
points made by camera rays and objects.
Best Regard
Wu Yang
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3dcc6dd1$1@news.povray.org>,
> "Wu Yang" <wya### [at] cswrightedu> wrote:
>
> > What I want is all the intersection points hitted firstly by the ray,
not
> > just those with the mesh object.
>
> By which rays? Every single intersection test ever made by the tracer
> while rendering, or just the ones from the camera?
>
>
> > The reason I found it in mesh.cpp is that the object I designed is
> > only made up by mesh object. Yes, Trace() function is called to
> > compute the color seen along the ray, but there is a variable called
> > Best_Intersection and I think this variable is the intersection point
> > I want.
>
> It is the nearest intersection Trace() finds. However, because Trace()
> is used to compute the color, there will be intersection tests that do
> not reach your code, because they don't call Trace(). I think Trace() is
> only used for the primary camera rays, reflected rays, and refracted
> rays, not for the trace() language function, shadow rays, or anything
> else that needs to trace a ray but doesn't need to compute the color
> seen along it. I don't know what you want to do with the data, so I
> can't make any better suggestions. If you would just tell us what you
> are doing, you would get much better help.
>
>
> > I really appreciate for all of your replies, your replies are very very
> > helpful to me. Maybe sometimes I can not express my question very
clearly
> > and make you feel a little boring. Sorry about that. I will try my best
to
> > make my question more clearly. Thanks a lot.
>
> Boring isn't the right term, "frustrating" is better. Trying to figure
> out what you want from vaguely worded questions and trying to understand
> why you are modifying these odd places in the code, especially when you
> ignore repeated questions about what you are trying to do.
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dcca947@news.povray.org>, "Wu Yang" <wya### [at] cswrightedu>
wrote:
> I want to compute the distance between the camera and the intersection
> points made by camera rays and objects.
If you don't need POV 3.5 and can take the data in the form of an image,
MegaPOV had a "depth" post process filter. You can also do tricks with
fog or textures to get a depth buffer. Use black textures and white fog,
so things get white with distance (or white textures and black fog, for
the opposite gradient), or texture everything with a spherical texture
centered on the camera and scaled large enough to contain the scene.
Otherwise:
Trace_Primary_Ray() in vbuffer.cpp and Trace() in render.cpp both return
the distance to the nearest intersection if there is one, or BOUND_HUGE
if there wasn't one. Look at the trace_pixel() function, you need to
save the results of Trace_Primary_Ray() and Trace().
If you can use depth data in an image and don't need the rendered image,
you could put the depth values in the rendered image by changing Color,
but it would be better to modify those two functions to skip the texture
and atmosphere calculations instead, it would be much faster rendering.
This won't work with focal blur, that would be a bit more work, but
probably isn't needed. You would have to decide what kind of depth
information you wanted there: minimum, maximum, midpoint of those,
average...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What you need is to buy and read a good C++ book or take a good course
> in C++,
Please excuse my ignorance, but what is C++ ?
Stephane
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1fldsiy.vlk33wyvge0cN%cassio@free.fr>,
> Please excuse my ignorance, but what is C++ ?
It's the language POV is written in. An extended version of C,
basically, but I don't know how much that means to you...if you don't
know what C++ is, you probably don't know what C is. If you want to
patch POV, you have to have at least a good grasp of C, C++ would be
better.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|