Hi, ingo.

> We, as hand coders, often forget what POV-Ray is. A ray-tracer, with a language
> 'bolted on'. So, yes, generate everything externally and render with POV-Ray, as
> long as it is faster. And if you do not want to edit the resulting scene.

Agree with you, such approach will hide SDL from the end user and make rendering
details transparent to him.

> Then a question for yesbird, can mathlab output to SVG? With a script/program
> SVG paths can be transformed to POV-Ray objects. I would not try it with
> POV-Ray's SDL. Just a thought.

Yes, it can, but I believe that SVG is unnecessary step, while we have access to
all internal ML data structures and can write scene directly.

> For 2D plots I would probably prefer SVG as it is dynamic scalable, where
> POV-Ray needs to re-render to another resolution.

Sure, but we can control it.

-- YB

Post a reply to this message

"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

> 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.

This is exactly what I am doing now )

> 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?

Yes, I mean this method:
https://www.mathworks.com/help/matlab/ref/isosurface.html

> 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?

Agree with you, for example soon I will modify my 'coneplot' to use 'native' POV
cones, instead of faces.

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

Thanks to your and Tor's samples I see that things are much more simple, than I
thought before. I modified 'surface' according suggestion (attached) and it
becomes more compact, readable, and writing much faster. Also manual data
control is possible in spreadsheet, if needed.

> 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.

This is exactly how it works now.

> 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.

Yes, this is the way I am following now - "macro is power" )

> 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?

Hope user will be not too lazy to write bug report to my github repository.

> 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?

I would call a macro and say: "just do it".

> - And I'm off to the races.

Happy racing )

-- YB

Post a reply to this message

Attachments:
Download 'surface3_make_mesh.pov.txt' (931 KB)

hi,

"yesbird" <nomail@nomail> wrote:
> ...

as the substantive points have been made already, I just want to add ($0.02 and
all that):

> Two main goals attract me most of all:
> 1. Substitute Matlab's standart visualizations methods, which users are already
> familiar with, by POV-based methods providing better image quality, ...
> 2. Extend Matlab's visualization system with POV entities ...

assuming the "average" Matlab user not to know POV-Ray, and having to install it
first, I think it will be important that your software outputs complete,
ready-to-render scenes, that is, ideally generate sets of .pov and .ini files,
plus, perhaps where data "dictates", .inc(s), to enable the prospective Matlab
users to use your s/ware without having to know/learn anything about POV-Ray as
such.


regards, jr.

Post a reply to this message

Hi, jr.
> assuming the "average" Matlab user not to know POV-Ray, and having to install it
> first, I think it will be important that your software outputs complete,
> ready-to-render scenes, that is, ideally generate sets of .pov and .ini files,
> plus, perhaps where data "dictates", .inc(s), to enable the prospective Matlab
> users to use your s/ware without having to know/learn anything about POV-Ray as
> such.
Absolutely correct !
This is the way it works now: set path to executable at setup, create scene by
API, press F5 and get rendered image inside 'Figure' window. Complete scene with
all includes stored in output directory and can be manually modified and
rendered if needed.

Post a reply to this message

hi,

"yesbird" <nomail@nomail> wrote:
> ...
> This is the way it works now: ...

does sound perfect.  :-)  nice.  out of interest, and since I'm v unlikely to
ever see the Matlab UI, maybe you could post a screenshot or two of what Matlab
users will see (your custom dialog?), once things are near completion.  cheers.


regards, jr.

Post a reply to this message

> does sound perfect.  :-)  nice.  out of interest, and since I'm v unlikely to
> ever see the Matlab UI, maybe you could post a screenshot or two of what Matlab
> users will see (your custom dialog?), once things are near completion.  cheers.

Thanks, with pleasure. Also few more or less ready examples available here under
'Examples' tab:
https://www.mathworks.com/matlabcentral/fileexchange/123520-pov-lab-matlab-interface-to-pov-ray

Any ideas and suggestions always welcome !
--
YB

Post a reply to this message

Attachments:
Download 'povlab_screen.png' (467 KB)

Preview of image 'povlab_screen.png'

Sorry, that's better.

Post a reply to this message

Attachments:
Download 'povlab_screen.png' (368 KB)

Preview of image 'povlab_screen.png'

hi,

"yesbird" <nomail@nomail> wrote:
> ...
> 'Examples' tab:

thanks for the screenshot ('todo', 'notes', I felt right at home :-)) and the
link.  looks all pretty polished, already ;-).  intrigued by the volume view, is
that a slice from 'mri.df3'?


regards, jr.

Post a reply to this message

Hi,

> thanks for the screenshot ('todo', 'notes', I felt right at home :-)) and the
> link.  looks all pretty polished, already ;-).  intrigued by the volume view, is
> that a slice from 'mri.df3'?

Always welcome, please be my guest :). It works stable now, but still too far
from perfect condition - I am only starting ...

As to volume, you are right, I am using this techniques:
https://home.chpc.utah.edu/~thorne/computing/L18_Povray_Part4.pdf

Please find the scene in attachment.

Post a reply to this message

Attachments:
Download 'volume.zip' (225 KB)