Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

130 Neutral

About coltdaniel

  • Rank
  1.   Thanks for the suggestion. The XY plane stuff worked as expected (normals always equal to (0,0,1)). But the unity sphere stuff show that there are problems. I took every point and divided by it's length relative to the origin to put them at a distance of 1 to the origin. The normals generated for these points are never equal to the points themselves, so something is wrong.   What I am talking about is related to what they are talking here: http://www.pointclouds.org/documentation/tutorials/normal_estimation.php
  2. This two points was an example that I choose to show that the result seemed strange to me. It has no practical use, nothing to do with a line, if I showed the real case with 243 points it would be harder to follow the problem. All I want to know is if I am understanding correctly what the procedure says. The idea is that if someone can read the procedure in the screenshot, it can make a quick check in my calculations and see if I did something wrong. In a conceptual way, like dividing by a number in each step of a summatory, instead only in the end, not in a arithmetic way.   For every point the in the set, it should create an approach of a normal. So it should be possible to "reach" the point by picking it and multiplying it by a constant. An example it is a point (6,8,0) that with an unitary normal of coordinates (0.6,0.8,0) would need a constant value of ten. But I am getting really weird values that can't be approximation errors, like a point with coordinates (-x,y,-z) and a normal for this point that it is (x,-y,-z), so that if I multiply it by a constant t or -t it can never reach the point I think it's fairly easy. It isn't for mesh generation, it's for generation normals for planes.
  3. Hello, I am doing some experiment with point cloud visualization, and found a procedure to generate normals from these point clouds. The idea is to use the points to generate the normal. The problem is that I may be misunderstanding what should be done. For instance, if I have two points with coordinates (0,0,5) and (0,0,10), so I expected the normal to be (0,0,1), in that way the point can be "reached" by taking the normal and multiplying it by a constant, but what I am getting it is a (1,0,0) or a (0,1,0) normal that can never "reach" neither of these points, so that's why I think I am doing something wrong. I attached an screenshot of the procedure, and here I will simulate my calculations done with these two points, so hopefully someone will be able to see a mistake.   Here is the screenshot:   [attachment=29452:Screenshot.png] Here is the simulation: H = [ || (0,0,5) - (0,0,5) || / 2 ] + [ || (0,0,10) - (0,0,5)|| / 2 ] H = 0 + 2.5 = 2.5 Wp (0,0,5) = e ^ [ (|| (0,0,5) - (0,0,5) ||) / 2.5² ] = e^0 = 1 Wp (0,0,10) = e ^ [ (|| (0,0,10) - (0,0,5) ||) / 2.5² ] = e^(5/6.25) = e^0.8 =~ 2.22 Mp = (Wp (0,0,5) * (0,0,5) + Wp (0,0,10) * (0,0,10)) / Wp (0,0,5) + Wp (0,0,10) = [1 * (0,0,5) + 3.22 * (0,0,10)] / 1 + 2,22 = (0,0,37.2) / 3.22 = (0,0,11.55) C = | (0,0,5) - (0,0,11.55) | = (0,0,-6.55) Inverse C = | (0,0) | | (0,0,10) - (0,0,11.55) | = (0,0,-1.55) | (0,0) | | (-6.55,-1.55) | Inverse C * C = |0 0 0 | eigenvalues = 0, 0, 45.307 |0 0 0 | |0 0 45.3| eigenvectors = (1,0,0) (0,1,0) (0,0,1) normal = (1,0,0) or (0,1,0)   Anyone saw anything wrong ?
  4. cowsarenotevil, yes that what I mean. Until a few moments before starting to write this thread, the "blackness" was giving me an impression of an artifact.   Ryan I can't see any faint circle on this image. My monitor doesn't have much brightness though. Any ideas of what I could do to see it?
  5. Hello, I am doing a Ray-tracer and I may be getting an visual artifact in a scene with a sphere projecting shadow on a plane. Here is:   As can be seen in the above screenshot, it is like the shadow is also projected in the bottom of the sphere in a reduced form. I checked all the calculations in a point located in this shadowed region to see if I could locate the source and my conclusions are this: The problem ain't during the first, direct bounce because the dot product between the light vector and normal is negative. This makes sense, since the light source is exactly above the sphere, aligned with it's center, so if the plane below the sphere wasn't reflective, all the bottom part of the sphere would be in the dark. Ok, then in the first reflection, the ray intersects the plane as expected, but the ray-sphere intersection algorithm says that a intersection happens, I checked the values one by one and everything seems fine. So where can be the error? After some thought I am starting to think that may not be one, that what this intersection means is that the ray hits the plane in a point where it is in the shadow due to the sphere, so none of it's red color hits the bottom of the sphere. But the image seems so unnatural that I am in doubt. What you guys think? Thanks for any suggestions.
  6. coltdaniel

    Reverse normal in ray-plane intersection

    Well, in my case I am just concerned about using planes to represent things like ground or sky, at least for the time being. So in this case I can ignore this reverse procedure, right ?
  7. Hello, I am trying to do ray-plane intersection based on this siggraph material: http://www.siggraph.org/education/materials/HyperGraph/raytrace/rayplane_intersection.htm and there the tutorial says that if the dot product between the ray direction and the plane normal is greater than zero then it usually should be reversed. Why? Since I don't know yet the reason, I also don't know if I can reverse it soon after the first intersection test for the first pixel and then forget about it, or if I can reverse it once only for the intersection rays (I am using orthographic projection, so the ray's direction is always 0,0,1) and then for reflection/refraction rays should I do the dot product test everytime? Someone could do the favor of clarify that out for me? 
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!