Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Jul 2009
Offline Last Active Nov 07 2015 02:40 PM

Posts I've Made

In Topic: Understanding procedure to create normals from a cloud point.

04 November 2015 - 10:31 PM

In that case, why not setup some simple test cases where you know the correct answer and try your algorithm? For example, if all the points in your point cloud are in the X-Y plane then the normal MUST be <0, 0, 1> (or <0, 0, -1>). Or you could try a huge number of points that are all exactly 1 unit away from the origin (a perfect sphere). In that case the normal at each point would be the point itself.


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

In Topic: Understanding procedure to create normals from a cloud point.

27 October 2015 - 03:24 PM

Pardon my laziness, I only read the first few sentences. How can 2 points have a normal? 2 points dictate a line. What would be the normal of a line?  If you want another vector that is 90 degrees perpendicular to this line, that can be achieved, but realized you can spin that vector 360 degrees about the line, and still hold 90 degrees perpendicular. Meaning there are infinite perpendicular vectors to your line.


Not sure what your actually using this for, but if this is for actual 3D mesh generation, throw the math book out and just grab local points to build triangles and then build normals off of those.


To your original question, sorry I have no idea.

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.

In Topic: Possible shadow artifact on the caster in a ray-tracer.

22 January 2015 - 06:08 PM

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?

In Topic: Reverse normal in ray-plane intersection

24 November 2014 - 01:22 PM

 You might want to be able to see through the back faces, or to ignore them because you have another plane at the same location but pointing the other way with different material properties.



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 ?

In Topic: Problem with arrayList

24 November 2009 - 11:02 AM

It ain't that. Note this code:

[sourcelang="java"]points = positionList.get(3).getPoints() + this.tournamentManager.get(tournamentNumber).getQuarterFinalistPoints();

When the first tourament is executed, the fourth quarterfinalist gets its number of points, which should be zero, since the tournament just finished. Then these points are added to the number of points that a quarterfinalist of the tournamet should receive.
The sum of zero with X points, is then updated to the player's constructor

After the second tournament is executed, then the fourth quarterfinalist of the second event (whoever is), gets its X points from the previous tournament and sum it with the Y points that the quarterfinalist of the second event should receive. After that, the new amount of points is updated.

So my code doesn't depend on the updatePoints method to make the calculation, this is done in the updatePontuation method, the updatePoints one is just a "setter" method.

Any more ideas?