Hi Sergey,

"yesbird" <nomail@nomail> wrote:

> It was a serious investigation, so I am a little ashamed that my question forced
> you to do so much work.

Well, it was a challenge to figure out what to do, for sure.   I was sitting
there staring at 4,802 vector entries in OpenOffice, thinking "How the
Fu....nction am I going to figure out if all of the adjacencies match up...?"

And then I outlined the triangles, which were arranged in a different manner
than I had expected, and got the idea to slightly separate them, and then put
colored spheres on, but singce they'd overlap, I had to "shrink" the corner
vector in toward the center.
Then I thought that maybe there was some kind of color-averaging that gave a
middle-gray in the middle of the interpolation, so I put the spheres in the
centers and connected with lines -

which showed that the problem if the vertices, and nothing in a spreadsheet or
evaluating adjacencies would have revealed anything anomalous - it's definitely
something that I needed to see.

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

> > _I think you can fix this by changing the axes that you're slicing along._
>
> Many thanks ! Now know where to look to fix it. In any case I decided to follow
> your suggestion and do all calculations in POV, passing only function or mesh,
> described surface, using yours and Tor's code, leaving present implementation as
> alternative.

Indeed.   I am a big fan of plenty of redundant options.

Just a few thoughts I had while cramming dirty pallet shrinkwrap into the
hydraulic compactor:

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.

(It would be great of we had linear regression, and singular value decomposition
/ principal component analysis   ...   I'm working on it)

Also, I'm curious as to what a VERY large "3D" thing would look like in MatLab -
something that extends deep into the screen.  It likely uses simple raster
graphics - whereas POV-Ray does things in "actual 3D", so the farther away it
gets, the smaller it gets - until it's less than a single pixel wide/high.

One final thing that most might not consider as a pertinent issue:
POV-Ray is open source, which means that anything that gets done in "POV space"
is freely available to anyone, "forever".

Considering the state of the world and the censorship and deplatforming and
corporate hijinks going on, it might be best to preserve as much accessibilty to
the data and the ability to manipulate and render it as possible, purely for
those reasons.
When will Matlab get bought by the WEF or infiltrated by "them"?  You could lose
your Matlab license, they could change the code, change the interface, change
the output, write the output in binary, or proprietary encrypted format, or put
spyware into their code package such that you'd rather not use it anymore.

Laugh all you want, but...    I'll start working on that tin-foil texture.

> >THIS ONE!  THIS ONE!  :D
> >#declare V = array[4802][9] {
> >//  VERTEX1    NORMAL1   VERTEX2   NORMAL2    VERTEX3    NORMAL3   COLOR1
> COLOR2   COLOR3
>
> Sorry, I missed it, assumed, that macro code is transparent and hence structure
> is 'self-explained'.

It is, of course, but I stumble blindly through most of these projects and
usually need some sort of Braille guideposts.  :P

> > I would also suggest that you orient all of you stuff the way POV-Ray does -
> > with a left-handed coordinate system, +x to the right, +y as up, and +z going
> > into the screen and away from you.
>
> I only want to make it compatible with ML's defaults and render from the same
> viewpoint as it does.

Understood.   It's pretty typical to convert scenes modeled in Moray or other
software packages that have different coordinate systems to POV-Ray - usually
using a transform {} matrix on the scene or the camera.

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.


Happy rendering,

- Bill

Post a reply to this message