Hi,
   I've rendered in povray what I am expecting with my trace scan script.

This way, you can clearly see what I have, what I expect and what I get 
instead!

First image shows my sphere { 0,1}
Second image shows the trace scan distortion on sphere { 0,1 }

Third image shows my torus { 0.7, 0.3 rotate x*90 }
Fourth image shows the trace scan distortion on the torus.

Hope this makes things more clear!...
   Xilo

-- 
Dedicated to audio/visual and interactive artwork.
Author of The Primary Colors of CSound:
http://www.geocities.com/simonlemieux/PCCS/index.html

Post a reply to this message

Attachments:
Download 'sphere-pov.jpg' (6 KB) Download 'sphere-gl.jpg' (31 KB) Download 'torus-pov.jpg' (8 KB) Download 'torus-gl.jpg' (23 KB)

Preview of image 'sphere-pov.jpg'

Preview of image 'sphere-gl.jpg'

Preview of image 'torus-pov.jpg'

Preview of image 'torus-gl.jpg'

Hi,

You seem to have a bug in the OpenGL application. If you render the code
below, you will see that the "trace" function works fine, and your data are
fine. They probably get messed up outside POV-Ray.

Perhaps a bad aspect ratio?

Regards,
Hugo


camera { orthographic
 right (image_width/image_height)*x
 location -4*y look_at 0 angle 48
}

#declare MyObject= sphere { 0,1 };


#local Z=-1;
#while (Z<1)

 #local X=-1;
 #while (X<1)

  #declare StartRay = <X,2,Z>;
  #declare SurfaceTouch = StartRay;
  #while(StartRay.y > -1)
     #declare SurfaceTouch = trace(MyObject, StartRay, <X, -2, Z>);

     #if(SurfaceTouch.x != 0 | SurfaceTouch.y != 0 | SurfaceTouch.z != 0)
       sphere { 0,.0125 translate SurfaceTouch pigment { rgb 1 } finish {
ambient 1 } }
     #else
       #declare SurfaceTouch = <0,-2,0>;
     #end

     #declare StartRay = SurfaceTouch;

  #end

  #local X=X+.025;
 #end

 #local Z=Z+.025;
#end

Post a reply to this message

> Perhaps a bad aspect ratio?

Ehh, not the ratio.. what was I thinking about.. it wouldn't give these
shapes! Anyway the problem is not POV. Good luck.

Regards,
Hugo

Post a reply to this message

> Ehh, not the ratio.. what was I thinking about.. it wouldn't give these
> shapes! Anyway the problem is not POV. Good luck.

Hmmm, then it is very strange because the values my script outputs are 
bad...  because my OpenGL program reads them in the 
What-You-Have-Is-What-You-See.

The problem is probably where the script writes to the disk...

Thanks I'll check that out!
   Xilo

-- 
Dedicated to audio/visual and interactive artwork.
Author of The Primary Colors of CSound:
http://www.geocities.com/simonlemieux/PCCS/index.html

Post a reply to this message

> Hmmm, then it is very strange because the values my script outputs are 
> bad...  because my OpenGL program reads them in the 
> What-You-Have-Is-What-You-See.
> 
> The problem is probably where the script writes to the disk...

I narrowed the problem and it is around my trace call...


I trace a ray from <X,2,Y> to <X,-2,Y>  and any hit gets written to the 
disk.

Now I checked if the hits I get have the same x and z values as my trace 
line, and about 99% of them dont.

I checked for those that have inconsistent XZ values if the vector was 
<0,0,0> and many of them are not...

So, with my current code as I understand it, the ray is diverted in 
another direction somehow...

Now that I eliminate every inconsistent trace returns (such as <0,0,0> 
and vector.x != X, etc...)  I get only two good surface hit on my 
object...  The two of them are on X = 0 and Z = 0;

Here is my updated code... can someone help me find where the problem is?

BTW, I'm sorry to switch Y for Z, I'll clarify that in future posts...

#macro TraceRay(X, Y)

#if(!defined( myFile))
   #error "Could not open temp.pov-stdout.txt"
#end
#write(myFile,  "  Y ", str(Y,5,2), "    ")

#declare StartRay = <X,2,Y>;
#declare SurfaceTouch = StartRay;
#while(StartRay.y > -1)
   #if(StartRay.x != X | StartRay.z != Y)
     #error "Inconsistent XY"
   #end

   #declare SurfaceTouch = trace(MyObject, StartRay, <X, -2, Y>);

   #if(SurfaceTouch.x = X & SurfaceTouch.z = Y)
     #write(myFile str(SurfaceTouch.y, 0,3), " ")
     // Good!
   #else
     #if(SurfaceTouch.x = 0 & SurfaceTouch.y = 0 & SurfaceTouch.z = 0)
       #debug "Got no hit at all!\n"
     #else
       #debug concat("\nGot hit with inconsistent XZ values: ", 
str(SurfaceTouch.x-X, 0, 10), "\n")
     #end

     // There was no hit, stop tracing...
     #declare SurfaceTouch = <X,-2,Y>;
   #end
   #declare StartRay = SurfaceTouch;
#end

#write(myFile "E\n")



#end



-- 
Dedicated to audio/visual and interactive artwork.
Author of The Primary Colors of CSound:
http://www.geocities.com/simonlemieux/PCCS/index.html

Post a reply to this message

Read the documentation on the trace() function, you are not using it 
correctly. It is working perfectly, exactly as designed. You set up the 
direction wrong, and your check for intersections will not work in all 
cases. That's all I'm saying about it, if you read the documentation you 
will figure it out.

-- 
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 wrote:
> That's all I'm saying about it, if you read the
> documentation you will figure it out.

"It traces a ray beginning at the point A in the direction specified by
the vector B."

If B was a point vector, and the direction was that from A to B, then
wouldn't you *indirectly* be specifying the direction by the vector B?
Maybe not, but it's easy to get confused. Is it really impossible to be
just a bit more understanding? it's not like he's the first to get
confused by it, so that might indicate that it's easy to get confused by
indeed.

Anyway Xilo, B is a direction, so if you want the ray to go downwards,
you should simply specify <0,-1,0> (or -y) regardless of what the
StartRay point is.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> Anyway Xilo, B is a direction, so if you want the ray to go downwards,
> you should simply specify <0,-1,0> (or -y) regardless of what the
> StartRay point is.

Thank you very much Rune, you simplified the impossible!  I just didn't 
realize it was a direction, it thought it was a look_at type!...

Now it works perfectly, though I have some bugs about my object which I 
which to correct, then I'll post a nice binary.images result image!

Thanks!
   Xilo

-- 
Dedicated to audio/visual and interactive artwork.
Author of The Primary Colors of CSound:
http://www.geocities.com/simonlemieux/PCCS/index.html

Post a reply to this message