06-14-2011 02:39 PM
FYI, my prior post is using his exact approach. I added '20 x i' to each image plane. Tomorrow I can fool with different values.
Because the non-ActiveX surface graph presently does not have the "w matrix" parameter that we have for the ActiveX surface graph (and therefore the approach to plotting multiple surfaces is different), there will probably have to be additional workarounds to try to get similar results for the 2 graph types.
06-15-2011 09:33 AM - edited 06-15-2011 09:35 AM
I added a control to adjust the Plane Spacing. This place spacing factor is multiplied by i (iteration number of the for loop) and added to the image used in that iteration.
When we get to a fairly large number (10000 shown here), we have effectively developed a workaround that allows similar viewing of multiple surfaces to the ActiveX surface graph using the non-ActiveX surface graph.
Christian - thanks for even bringing this possibility up in the first place.
Sincerely,
Don
06-15-2011 10:10 AM
Here's 87 slices rendered:
06-15-2011 10:42 AM
THank you for the update and report about the work-around.
But now that you are being forced to take another route...
Did you by any chance check-out the "Iso-surface" stuff that is included in the BioMed toolkit?
It LOOKS like it could render your shape by creating a surface from interpolations between the samples in each of your surfaces.
Just curious.
Take care,
Ben
06-15-2011 10:54 AM - edited 06-15-2011 10:55 AM
Yes, I am aware of the multi-surface / volume rendering possibility in BioMed toolkit. I would like to use it. However, right now, I am using 64-bit LabVIEW for which a version of that toolkit is not available (nor is a 64-bit version of Mathscript RT which the toolkit needs to run).
Sincerely,
Don
06-16-2011 07:37 AM
@DonRoth wrote:
Yes, I am aware of the multi-surface / volume rendering possibility in BioMed toolkit. I would like to use it. However, right now, I am using 64-bit LabVIEW for which a version of that toolkit is not available (nor is a 64-bit version of Mathscript RT which the toolkit needs to run).
Sincerely,
Don
Forgive me if I have read too much into your posts over the years Don but, you don't strike me a person that screams bug while on the other hand, if I find any delta between the old and new I declare it a bug becuase it prevents upgrades without developer involvement.
So...
In your opinion, should the lack of a W vector or the weird belnding of muliple surfaces be decalred a bug?
You partner in 4-space.
Ben
06-16-2011 08:21 AM
I don't know if I would call the lack of W matrix a bug. My feeeling is that it would be nice to have consistent programming features between the old way of doing things and the new, so as not to have to develop work-arounds which can be time-consuming. On the other hand, we don't want to slow new development that might result in better performance. Since you were the pioneer in helping decipher multiple surfacing for the 3d ActiveX surface plot, you might have some thoughts on this as well.
Sincerely,
Don
06-16-2011 09:53 AM
If the intent of the 3D graphs is to replace and augment the CW version then the lack of the W vector is a bug.
Since the CW does not seem be getting any attention and the day of the 3D and 4D graphs is just now dawning (now that we have machine that can do the work) I fell the lack of the W-vector is a short-coming that should be fixed.
Ben
06-16-2011 10:22 AM
Please correct me if I'm wrong but isn't the color matrix input the equivalent of the w matrix?
06-16-2011 10:33 AM
Ahh, I just noticed that the color matrix input is only available on the Native 3D Graphs (the 3 on the bottom row of the palette), not on the 3D Math Plots. Definitely seems like it should be added to the 3D Math Plots as well.