POV-Ray : Newsgroups : povray.general : POV-Lab: plans and discussions : Re: POV-Lab: plans and discussions Server Time
19 Apr 2024 07:12:15 EDT (-0400)
  Re: POV-Lab: plans and discussions  
From: yesbird
Date: 1 Feb 2023 03:45:00
Message: <web.63da24641a3112305f3e868110800fb2@news.povray.org>
> 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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.