So, I'll just post a few more thoughts here:

The file is big.   Huge, in fact.  33,642 lines of code.
All of it is hard-coded, and there's no easy way in POV-Ray or by importing the
file into a spreadsheet to work with the data.

Your primary data is the vertex location, its normal, and its pigment.
I would suggest writing those into a 2D array.

Then you loop through it and have a small amount of actual written code that
converts those all into the triangles of your mesh.

Better would be to convert that into a mesh2, which would further reduce the
amount of data, and likely address the color/normal mismatches.

I'd like to draw all of the normals for each vertex - but I really can't because
there's no data structure in the code.   It's all individual objects.

I can't really import it into a spreadsheet, because the data is all over the
place, and the indentation / leading text is all different.   If the data were
all collected /isolated on their own lines, I could possibly filter it all out.
The color data is on different lines than the vertex location and normal data.
Not a big deal - just a little more spreadsheet work.
But organizing that into an array declaration would put it all together nicely -
both "spatially" in the ASCII file, and (better yet) in a data structure that's
accessible to the user natively in SDL.  I can loop through it ALL, sort it,
compare it, graph it, use it to make normal arrows, etc.

If I were an end user of your utility, I'd probably desire such capability.

I might like to use the surface to illustrate a computer graphics textbook or a
calculus book, and show how the tangents and normals are calculated, buth
analytically and numerically.  I might want to label individual triangles,
highlight them, outline them, manipulate them as groups (triangles with shared
faces, triangles that share a common vertex, triangles in the same row or
column...).  And to do that, I'd need ready access to where the triangles are,
and the data that is used to create them.  If they were in arrays, I could
number them individually either by numbering them in the array at the outset,
using a counter, or by calculating column + (row*columns), I could also
calculate the min and max extents and use that to draw arrows, ... you get the
idea.

Your textures are all split up and hard coded as well.
If they were assigned as part of the triangle-making code, I could easily make
changes to the whole surface by adding a normal or a different finish to that
code, but there aren't many people who are going to want to recode 1600 smooth
triangles by hand.

I could even throw a branch into the loop, where #if (array index = "That one!")
then I could give it a highlight, outline, not render it, change the color,
texture, normal, finish, whatever.  I could alternate triangles based on
odd/even array index to give a sort of harlequin pattern, or choose odd/even of
the sum of x & z to give a checkerboard.  I can use the vertices as Voronoi
centers.  The mesh is not a closed mesh, so I can't use it in CSG.  If I knew
where the 4 corners were, I could just append 2 big triangles to the bottom.
Done.

Code is power.   That's why we're using computers - to handle digital data.
The current output is not much better than a hardcopy.  Yes, I can open the file
in POV-Ray and render it, but it's basically a static scene.

The more generalized a form that you store the raw data in, the more versatile
your scene file is, and the more useful it is to the end user, because they can
easily access and manipulate the data in a meaningful and easily understandable
way.

And that brings me to another way that you could approach this.
If your end users are going to be using POV-Ray anyway, why have MatLab export
all of the POV-Ray specific bits of scene code?

Why not just have MatLab export the DATA, and then write some macros in SDL that
will process the data into the forms that the user wants to render?

If you know the equation, then you can write that to a file in a way that people
can use it in an isosurface.  Or a parametric.  You have my scene file that
shows how to make it into a mesh.  I think I may have coded a mesh2 in the past.

Then you could write all that data into an include file, and simply let the
macros chew on the data in the include file in any way you or the end-user would
like.  Writing SDL code in MatLab so that MatLab can write the SDL code to and
SDL file just seems - like a lot of wholly unnecessary work.


But that's just my take.   You may have MatLab reasons for doing things a
certain specific way, but maybe there can be a whole lot of initial set-up work
that's completely avoidable - there's 30 years of scene files on this server -
and then you can start getting results, head right into testing, and spend that
90% of your time working on refinements rather than ascending from the beginning
of the learning curve.


- Bald Eagle out.

Post a reply to this message