"yesbird" <nomail@nomail> wrote:


> As to scene structure and editing, I am generating it by Matlab script, so
> manual editing is not assuming, but in any case I see that moving to mesh2 is a
> must, at least to save time for parsing.

To be honest, you're going to parse and render simple scenes like this in
seconds, so it's not much of an issue.  I'm just not sure how large things might
get in the future, or how many such objects would be rendered or parsed in a
scene by any given user.

So as far as all this goes:

Create camera object and put it in separate include file to save rendering time
in future

Create lights objects and put them in separate include file to save rendering
time in future

Create environment objects and put them in separate include file to save
rendering time in future

Id say you're shaving off milliseconds at most.  Keep it in the file so it's a
standalone render.

As far as manual editing, you might have someone making a diagram, or changing
the texture of a specific grid square to highlight that portion of the equation,
or ....   so the output of your scripts might only be the beginning of someone
else's workflow.

And as far as that goes, people might very well use your utilities for making
illustrations for documents or slides for presentations - and so you might start
thinking ahead with regard to offering a side-by-side layout showing what
equation is being graphed, numbering or graphing macros/algorithms written by
myself, Tor, and the excellent Tabulated system developed by jr.
Just some things to mull over when you're trying to get to sleep.  ;)  :D

> And for sure, I am using versioning system, it's here:
> https://github.com/syanenko/POV-Lab

I meant as a comment block in the scene file itself.  It's always nice to be
able to tell where a file came from (and when) and sometimes by who.   Including
the version of MatLab and POV-Ray at the time of creation helps solve future
archaeological mysteries.
"Who the heck wrote THIS code???"    "Ohhhhh... 'automatically generated by...'
  plus it was made 15 years ago when computers were slow and POV-Ray was still
in version 3.8, so they didn't have features x, y, and z"

As you can see, you got tricked into seeing and misinterpreting a problem with
reflections.   I'd keep things simple for visibility purposes, and also
reflections are costly in terms of render time.
As you progress in developing your scripting, you can experiment with different
colors, textures, normals, and finishes.  This will make it easier for a viewer
to correctly interpret the mathematical surface being represented using the
available visual cues.  So good shadows, a small surface normal, and some
specular highlighting can go a long way.

http://warp.povusers.org/povtips/

Also, if you're going to provide text, I'd choose something that represents
mathematical symbols well, and does a good job with regard to readability and
differentiating things like 1 and l, O and 0, etc.

You might consider Atkinson Hyperlegible font
https://brailleinstitute.org/freefont

IIRC I've also had good success with Arial Unicode MS and Lucida Sans Unicode.

Others have suggested SF Mono, JetBrains Mono, IBM Plex Mono, Source Code Pro,
Fira Code, Fira Mono, and Recursive Mono.

There are also other graphing / mathematical visualization packages the use
POV-Ray that you might look to for inspiration.

Post a reply to this message