3D Picture Control, two sided lighting

[wiebe@CARYA]

---

@Intaris wrote:

I tried duplicating the points, setting ambient and diffuse to full transparency, inverting the normal for the second set of points....... Trying to get only specular lighting. Didn't work (or at least I couldn't get it to work, those two statements are very much not equivalent.... 🙂 )

---

I tried it to, and it did work:

[wiebe@CARYA]

---

@IFW wrote:

rendering as polygons/triangles isn't an option, I'll be working with large, un-ordered point clouds of >30,000,000 data points so generating a solid mesh from these would be highly computationally intensive.

---

That doesn't make sense at all.

OpenGL will render those points as triangles.

I wasn't suggesting to render a solid triangle mesh. I was suggesting to replace each point with a single triangle. That is what I did in the previously posted image. The triangle size can be adjusted, like the point size.

[IFW]

I misunderstood the suggestion then, read it as rendering the whole mesh as a single surface of triangles (if you get my meaning). can you post the code for the working image?

[wiebe@CARYA]

---

@IFW wrote:

I misunderstood the suggestion then, read it as rendering the whole mesh as a single surface of triangles (if you get my meaning).

---

It's rendered as a mesh of "triangles", so not a "Triangle Fan" or "Triangle Strip".

The idea is quite simple (way to complex actually).

The normal X random_vector = vector_perpendicular_to_the_normal. If we normalize it, and calculate vector_perpendicular_to_the_normal X normal, we get two vecots perpendicular to the normal, and each other. Adding those vectors to the origin of the point, gets us three points on the plane perpendicular to the normal. The normal pointing forward. So we only render the front face. Then, negate all normals and triangles, and render those front faces...

The difference between the points is that the points stay their size in pixel space when closing in. The triangles will grow as they come closer, like all 3D objects.

Not sure if it's a working solution, but it looks 'neat'. It seems pretty fast for the subset.

I took all sorts of shortcuts, just to get things working fast. you might want a triangle with the point of origin as center, for instance... Fronts and backs should be reversed, ideally.

---

@IFW wrote:

can you post the code for the working image?

---

Yes! Enjoy.

[IFW]

Ah, now it makes sense, in a way that works but it does cause LabVIEW to struggle once I start working with the full size clouds >3,000,000 data points.

I may see if I can adapt the idea however.

[Ben]

---

@IFW wrote:

Ah, now it makes sense, in a way that works but it does cause LabVIEW to struggle once I start working with the full size clouds >3,000,000 data points.

I may see if I can adapt the idea however.

---

Please let us know if you succeed and what you had to do to accomplish that goal.

My adventures back in early days of the 3D picture control resulted in "Out of Memory Errors" if;

my data set too large

OR

I wanted to switch to another data set.

Thank you!

Ben

[wiebe@CARYA]

---

@IFW wrote:

Ah, now it makes sense, in a way that works but it does cause LabVIEW to struggle once I start working with the full size clouds >3,000,000 data points.

I may see if I can adapt the idea however.

---

Yes, it's reasonable that 3000000 points are faster to render then 3000000 triangles. Not only more data (coordinates) to process, but also potentially more surface as the points stay their size, the triangles grow.

3M polygons doesn't sound that much, modern graphic cards should be able to render that, I think?

It would be worth knowing what causes the struggle. I can imagine the preprocessing takes time. That could probably be optimized (but only if it is a bottleneck).

Perhaps rendering the fronts and backs in two separate objects will be faster? Could be worth a try. Not sure why it would be faster, but it just might be. If it is faster, splitting it up in even more objects might help.

This is just like vision. All these ideas, every single one taking an effort to explore, and resulting in more ideas. And there's always a change the best solution is something completely different...

[IFW]

It's the pre-processing time I'm working on reducing now which has lead to some interesting observations:

• we don't need to render each quad twice with opposite normals, rendering once with no culling provides the same result.
• creating a mesh of quads or triangles and setting the DrawStyle.Mode of the object (not mesh) to points results in points that show the correct specular response and resize as you zoom however there is one point for each vertex of your quad/triangle. whether this could be used to reduce pre-processing time I'm not sure..

I've attached a snippet of my current pre-processing below:

[wiebe@CARYA]

---

@IFW wrote:

It's the pre-processing time I'm working on reducing now which has lead to some interesting observations:

• we don't need to render each quad twice with opposite normals, rendering once with no culling provides the same result

---

Hmm. I tried that (actually in the disabled case) first, but it did not look good. It looked exactly like the point rendering.

---

@IFW wrote:

• creating a mesh of quads or triangles and setting the DrawStyle.Mode of the object (not mesh) to points results in points that show the correct specular response and resize as you zoom however there is one point for each vertex of your quad/triangle. whether this could be used to reduce pre-processing time I'm not sure..

---

In your snippet the DrawStyle.Mode is set to Polygons though?

A quad (2 triangles) will be slower then a triangle. Ideally, I'd create a vector perpendicular to the normal, scale it (only once!), and then rotate it twice with 120 deg. around the normal. That would give a triangle with the origin as center.

---

@IFW wrote:

---

I started out with a random vector, but thought a rotated normal would be safer. Guess it's mood. Both vectors are very unlikely to be parallel. Guess if you want it really safe, you'd check if the product has an error, and if so, generate a new random vector...

I'm not sure the Unit Vector.vi is faster then the LV normalize, it calls a dll… Benchmarks would be required...

Doing the quad scale before negating\duplicating the vectors will save half the multiplications.

[IFW]

I left DrawStyle.Mode as polygons as at present we prefer the visual style of squares over 4 clustered points for each square (and squares over triangles), if you swap the DrawStyle.Mode to points you'll see that each rendered point reacts correctly to light from both faces, you just get more points than necessary.

I agree that there is scope for further optimisation and benchmarking on all the pre-processing and that if we decide to go with squares over triangles that we have to accept a performance decrease.