"yesbird" <nomail@nomail> wrote:
> > I think that the best thing to do would be to collect a number of representative
> > MatLab visualizations to use as targets for emulating in POV-Ray.
>
> I've started with:
> 1. https://www.mathworks.com/help/matlab/ref/plot.html
> 2. https://www.mathworks.com/help/matlab/ref/surf.html
> 3. https://www.mathworks.com/help/matlab/ref/coneplot.html
> 4. https://www.mathworks.com/help/matlab/ref/streamline.html
> Basic implementation is ready, but needs some polishing.

Yes, but what I mean, is actual concrete examples that have specific attrubutes
that you want to have.   Then Step 1 is to simply try to copy that in SDL as
closely as possible, to get the relevant code fleshed out.   After that, it
would be about making the code more efficient, and thinking about the interface
between MatLab's output and the limitation of POV-Ray to handle any given data
structure.


> And for the start it's enough, much more interesting to concentrate on POV CSG
> entities, which ML don't have.

I think that you mentioned that MatLab could do isosurfaces?   Doesn't CSG just
work with the same min/max type operations that one would do in something like
Shadertoy?




> 2. Pass only minimal necessary data (formulas and params) and let the macros do
> the rest: all geometry, normals and colors calculations. This is the approach
> you are suggesting.
> Pros:
> Will work much faster (I've compared the working time of your code for
> 'surf' and mine).

Well, I'm only familiar with the SDL side of it, and so you need to balance that
with what you know of MatLab.
I'm also thinking that for certain things that you may want to do, a hybrid
approach may be not only desirable, but necessary.  Converting _everything_ to a
mesh might not be the best route.

So, for example, why turn spheres, cones, cylinders, boxes, etc into meshes,
when POV-Ray has those as mathematical primitives already?  Also, the smaller
the diameter you have, the more triangles you're going to need in order to wrap
around that smoothly, ahich kind of defeats what you're trying to achieve -
simplicity and aesthetics (no artifacts).

> Cons:
> Need to learn POV macro language at expert level to get best results.

Well, there is no "macro language" - it's just the same SDL inside a wrapper.

At this point, not knowing exactly how this is all going to work, I'm just
suggesting that commands like plot and plot3D can just be macros that take the
same parameter inputs as Matlab and do the same thing, only in POV-Ray.  And
since the command/macro names are the same, and the parameters are the same -
there's really nothing to "learn", except for maybe some small modifications in
representing the input. (Just like Excel uses a comma, but OpenOffice uses a
semicolon instead)




> Not sure that some ML users will like to change the ML environment for something
> else. The main idea of the project is to provide ML's users power of POV
> visualization keeping simple and familiar ML's language, UI and API.
> SDL is very powerful, but sophisticated and difficult to learn for inexperienced
> users, so I decided to hide it from their view.

So the idea that you have is to write the data to a file, and then call POV-Ray
automatically and just have it render whatever got exported.

So, one question then is: can Matlab just export a list of the commands that the
user wants to render?  Because then you could just write macros to handle all of
the rendering tasks, Matlab could export the command names that the user wants
to perform, and then with minimal massaging of the literal Matlab command lines,
 that would serve as an include file for POV-Ray to run those macros.

Again, just another idea.

Also, with regard to SVG - I've written a limited number of small scripts to
turn some SDL stuff into SVG, for laser-cutting.  Seems like it's all mostly
Bezier-spline type stuff, which is scalable.


I'm also thinking, that if something goes wrong between Matlab and POV-Ray,
where do we look to debug it?   Who do we ask?  The user?  You?  Here?

All the math is the same, it's the POV-Ray code that will likely need to be
modified.

If you wanted to tell me in Russian what I needed to do, would you want to
describe _everything_ and have to translate it all?  Or would you just want to
tell me the goal, and let me work it out on my own, in my own language?
Similarly:
Why describe every operation (every vertex normal and color) when Someone can
say in MatLab what they want to do, and POV-Ray will understand the task, and
just do what it knows it needs to do.

- And I'm off to the races.

- BE

Post a reply to this message