 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, guys !
As I see my POV-Lab has some resonance in this group and according to BE advice,
I am starting new thread where would like to share my plans about this project
with everyone who is interested in and can assist with advice or maybe even
development. We can discuss all related staff here.
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, I mean
at least following functions: 'plot', 'surf', 'coneplot', 'isosurface',
'streamline', and similar. Here is the reference to corresponding manual
section:
https://www.mathworks.com/help/matlab/2-and-3d-plots.html?s_tid=CRUX_lftnav
2. Extend Matlab's visualization system with POV entities and methods that far
exceed present Matlab's abilities with the power of CSG: making slices, unions,
intersection of surfaces, displaying normals and highlighting faces, etc.
I guess it can be very useful for:
1. Presentations. Starting from basic forms, and dreaming about the distant
future, special methods for presentation graphics (bars, charts, pies, etc).
2. Learning CG in schools and universities. I can imagine LiveEditor's notebooks
(relatively new Matllab's feature) that covers some aspects of CG and can be
used as lesson materials.
At present time the state is very early beta: we have a basic core and few
examples that work, but are too far from perfect.
Even without Matlab you can see examples from the latest published revision
here:
https://www.mathworks.com/matlabcentral/fileexchange/123520-pov-lab-matlab-interface-to-pov-ray
by selecting the 'Examples' tab.
I am planning to publish revisions weekly, to make new features available to
users as soon as they appear, some minor imperfections, if any, I will fix 'on
the fly'. Code repository is here: https://github.com/syanenko
No doubt, it will be a long way, but you know, that "a journey of a thousand
miles begins with a single step", hope with your support it becomes much
shorter. Will be glad to hear your opinions, advices, and constructive (and also
destructive) critics.
PS: Sorry for my English, it's not my native language and I am working with code
much more than with English literature :).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"yesbird" <nomail@nomail> wrote:
> I am starting new thread where would like to share my plans about this project
> with everyone who is interested in and can assist with advice or maybe even
> development. We can discuss all related staff here.
>
> Two main goals attract me most of all:
>
> 1. Substitute Matlab's standart visualizations methods
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.
On this end, I would say that an essential part of implementing what you want is
going to be understanding what a typical setup and workflow looks like, and what
parts MatLab and POV-Ray are going to play in the overall scheme of things.
What are the outputs from Matlab going to look like? That's going to determine
a lot.
A lot of those small functions in the manual look just like small macros I'd
write to perform the same operations.
> 1. Presentations. Starting from basic forms, and dreaming about the distant
> future, special methods for presentation graphics (bars, charts, pies, etc).
These should be fairly trivial to set up.
> Even without Matlab you can see examples from the latest published revision
> here:
>
https://www.mathworks.com/matlabcentral/fileexchange/123520-pov-lab-matlab-interface-to-pov-ray
> by selecting the 'Examples' tab.
Most if not all of that will be stuff that the late Friederich Lohmueller set up
and incorporated in the POV-Ray drop-down Insert Menu.
I have most of his website archived, and it looks like that's now one of the
projects I ought to work on making available again, since the site is down.
> PS: Sorry for my English, it's not my native language and I am working with code
> much more than with English literature :).
No worries. You English is just fine, and we have people from all over the
world post here, some even only by using online translators.
One of the things that we should know is - what can MatLab do that POV-Ray
can't?
And which parts of the workflow are you going to have POV-Ray do? Because if I
were going to start a project like this, I'd probably just start emulating
MatLab in POV-Ray, and then the learning curve for people who already know
MatLab would be a lot easier.
There's a lot of things that you can do with regard to the graphics capabilities
of POV-Ray. And I mean A LOT. So much that i can't hold it all in my head,
and so much that it's easy to get lost and paralyzed because there are TOO MANY
options to pick from.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Next I will take:
5. https://www.mathworks.com/help/matlab/ref/streamtube.html
And for the start it's enough, much more interesting to concentrate on POV CSG
entities, which ML don't have.
> On this end, I would say that an essential part of implementing what you want is
> going to be understanding what a typical setup and workflow looks like, and what
> parts ML and POV-Ray are going to play in the overall scheme of things.
>
> What are the outputs from ML going to look like? That's going to determine
> a lot.
>
> A lot of those small functions in the manual look just like small macros I'd
> write to perform the same operations.
Sure, I see two options:
1. Let ML generate geometry, normals and colors and export this data to POV.This
is how present implementation works.
Pros:
Less work in POV, no need to write (and learn) macros.
Cons:
Works slowly - loop over ML's structure and writing big data to scene files
takes a lot of time, while rendering is _much_ faster.
I am prefer to get closer to real time execution, as much as possible.
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).
No need to explore ML's data structures for parsing and export.
Cons:
Need to learn POV macro language at expert level to get best results.
I am still in doubt ...
>
>
> > 1. Presentations. Starting from basic forms, and dreaming about the distant
> > future, special methods for presentation graphics (bars, charts, pies, etc).
>
> These should be fairly trivial to set up.
>
> Most if not all of that will be stuff that the late Friederich Lohmueller set up
> and incorporated in the POV-Ray drop-down Insert Menu.
Yes, this will be the most easy part - a large amount of entities, but work
itself is formal.
> I have most of his website archived, and it looks like that's now one of the
> projects I ought to work on making available again, since the site is down.
It will be interesting to look at this content to find some new ideas and/or
techniques.
> One of the things that we should know is - what can MatLab do that POV-Ray
> can't?
You know, that's too many to describe ). POV does only visualization, Matlab is
a system for scientific calculation.
> And which parts of the workflow are you going to have POV-Ray do? Because if I
> were going to start a project like this, I'd probably just start emulating
> MatLab in POV-Ray, and then the learning curve for people who already know
> MatLab would be a lot easier.
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.
-- YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> wrote:
> And which parts of the workflow are you going to have POV-Ray do? Because if I
> were going to start a project like this, I'd probably just start emulating
> MatLab in POV-Ray, and then the learning curve for people who already know
> MatLab would be a lot easier.
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.
Some time ago I have converted the meshmaker macro's and the parametric mesh to
the Nim programming language. A one million triangle sphere in 0.4s written to
file. 0.4 sec for POV-Ray to parse the mesh from file. (An isosurface mesh
program may be nice but not within my capabilities.)
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.
For 2D plots I would probably prefer SVG as it is dynamic scalable, where
POV-Ray needs to re-render to another resolution.
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
