POV-Ray : Newsgroups : povray.programming : About Intersection points Server Time
6 Oct 2024 13:53:09 EDT (-0400)
  About Intersection points (Message 11 to 17 of 17)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Warp
Subject: Re: About Intersection points
Date: 8 Nov 2002 16:17:27
Message: <3dcc29e7@news.povray.org>
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

From: Wu Yang
Subject: Re: About Intersection points
Date: 8 Nov 2002 21:07:13
Message: <3dcc6dd1$1@news.povray.org>
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

From: Christopher James Huff
Subject: Re: About Intersection points
Date: 8 Nov 2002 22:01:54
Message: <chrishuff-6D3036.22014508112002@netplex.aussie.org>
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

From: Wu Yang
Subject: Re: About Intersection points
Date: 9 Nov 2002 01:20:55
Message: <3dcca947@news.povray.org>
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

From: Christopher James Huff
Subject: Re: About Intersection points
Date: 9 Nov 2002 12:24:27
Message: <chrishuff-B89E79.12242009112002@netplex.aussie.org>
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

From: Stéphane Nicolet
Subject: Re: About Intersection points
Date: 9 Nov 2002 12:52:44
Message: <1fldsiy.vlk33wyvge0cN%cassio@free.fr>
> 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

From: Christopher James Huff
Subject: Re: About Intersection points
Date: 9 Nov 2002 13:04:22
Message: <chrishuff-8EE04E.13041609112002@netplex.aussie.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.