> Anyway, it makes for a good rule of thumb - "always slice meshes parallel to the
> texture gradient".  :)

Well said ! :)

> Matlab probably has a lot of routines that allow the user to manipulate
> arbitrary data in ways that POV-Ray currently cannot.  Data that has no equation
> that it's derived from.   Random points, measurement data, statistics, etc.

Yes, this is the case when we can pass data, not formulas and POV will do the
rest.

> Also, I'm curious as to what a VERY large "3D" thing would look like in MatLab -
> something that extends deep into the screen.

I have experience working with Point Cloud toolbox and it was a sad experience -
works too slow, visualization is poor.

> One final thing that most might not consider as a pertinent issue:
> ...
> Laugh all you want, but...    I'll start working on that tin-foil texture.

Not so funny as it could be at least 10 years ago :(. I thought about all this
things before start sticking to ML, and know that there is some risk here.

This is the reason, why I am prefer R for some of my projects and trying to
separate SDL code from ML as much as possible for easely porting it to R in
future, using the same *.inc called from different language.

> When most everything is worked out and running, it probably won't be that big of
> a deal, but for debugging sanity, it might be worth putting labeled axes in the
> scene, and defining the transform matrix at the top of the scene, with a few
> lines of comments describing exactly what it does and why it's there.

You are right - accepted )

--
YB

Post a reply to this message