> 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
> 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 )
Post a reply to this message