3D Picture Control, two sided lighting

[wiebe@CARYA]

Could you post the VI? Maybe with even less (or no) data?

If I render only one pass (e.g. one normal, no culling) I don't get the correct results.

[IFW]

I've attached my current code (without data), I've also done a reasonable amount of optimisation on the calculation of the quad primitives.

[wiebe@CARYA]

Note that pre allocating the array and then replacing the elements is not faster then using the auto indexing. Or at least is shouldn't be. It used to be, but the compiler will do that at least just as efficient Unless maybe if the loop has a conditional terminal, but even then. That's probably just a lot of work and clutter without any benefit.

The lightning seem right, but I do get object further away shining through the front objects. Didn't have that with the duplicated data set w\ culling:

[IFW]

Interesting I hadn't noticed that error...

with regards to the pre-allocation I wasn't certain (and haven't tested) whether auto indexing is still faster when you're building an array within an array and concatenating the result, the code I sent certainly represents the fastest I've tested so far.

[Intaris]

---

wiebe@CARYA wrote:

---

@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:

---

Yup. me not getting it to work and it generally not working are indeed two different things.

[wiebe@CARYA]

---

@IFW wrote:

Interesting I hadn't noticed that error...

with regards to the pre-allocation I wasn't certain (and haven't tested) whether auto indexing is still faster when you're building an array within an array and concatenating the result, the code I sent certainly represents the fastest I've tested so far.

---

With a fixed size for loop, LabVIEW should pre-allocate the memory itself, nowadays. Now it doesn't hurt to do it, but it probably pays of only when the output array size isn't the nr. of iterations of the for loop.

[Ben]

---

wiebe@CARYA wrote:

---

---

With a fixed size for loop, LabVIEW should pre-allocate the memory itself, nowadays. Now it doesn't hurt to do it, but it probably pays of only when the output array size isn't the nr. of iterations of the for loop.

---

I have tried it out head to head and doing it explicitly, seems to be slower than letting LV do it.

I admit I have not tried using a concantenating tunnel with variable sized arrays being appended... but then again, we would have to "cheat" to allocate enough memory in that case.

Ben

[IFW]

my testing shows that in this instance where I'm building an array inside the loop and concatenating the arrays together to form a larger 1D array it's faster to pre-allocate an array and replace elements than use the concatenating terminal, with an input array of 2.5M data points it's ~500ms faster to pre-allocate.

[wiebe@CARYA]

Hmm. Conflicting results. Interesting!

We could add for loop parallelism to the mix. The auto indexing will allow for loop parallelism, the pre allocation won't.

[IFW]

the differences are likely to relate to different hardware setups, benchmarking performance is notoriously difficult.