"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I worked out my own scene, using your equation, storing the <x, f(r), z> in
> a 2D array, analytically calculating the vertex normals using fast forward
> differencing to get the tangents by numerically approximating the partial
> derivatives, then taking the vector cross product, and then making a mesh with
> smooth_triangles with per-vertex normals.
>
> (After horribly botching that 5 times in a row, I got the normals, and therefore
> the triangles all working nicely.)
>
> No textures for any of the triangles.
>
> mesh {
>  loop over arrays to make triangles
> texture {gradient y}
> interior_texture
> }
>
> I get a much steeper curve than you do, so I don't know if there's some kind of
> scaling going on somewhere in the process.
>
> I hard-coded the pigment_map for the texture, but it could probably be
> calculated from the HSV2RGB macro in colors.inc

Looks nice and smooth ! Could you share the code, please ?
I am continue struggle with Matlab's generated data )

Post a reply to this message

"yesbird" <nomail@nomail> wrote:

> Thanks, I'v checked it - normals are normal.

So, I'd say that you need to check your pigments for adjacent triangles, and
make sure that your vertex normals match for all triangles that share that
vertex.

Although the normals may point in the proper "facing" direction, they may not
all be pointing in the same precise direction where neighboring triangles all
meet at a corner vertex.

The thing that I'm most concerned about at this point is that there are so many
different approaches to accomplishing something in SDL, that you may be coding a
large number of single-use cases.

If you started a new thread, and gave a broad overview of all the different
types of things that you're wanting your rendering package to do, then we could
look at it and find some commonalities and propose some more generally
applicable approaches.

Not everything translates smoothly, or well, to SDL.

So, you could write your vertices to an array, and then calculate face normals,
and use the array to make the mesh.
You could loop over the array a second time, and sum all of the normals for the
SIX faces that share (almost) every vertex (except edges), then normalize that
sum.
You could write all your vertices to an array and write the normals to an array
- but rather than overwrite shared vertex normals, add to what's already there,
then do a final pass to normalize them all, or normalize it in the triangle
normal code.

There are lots and lots of different options.

- BW

Post a reply to this message

"yesbird" <nomail@nomail> wrote:

> Looks nice and smooth ! Could you share the code, please ?
> I am continue struggle with Matlab's generated data )

Sure - let me know if you have any questions.  I'm for nearly another 2h.

Post a reply to this message

Attachments:
Download 'ripple.pov.txt' (5 KB)

> Sure - let me know if you have any questions.  I'm for nearly another 2h.
Thanks, it works fine. I will examine it more carefully tomorrow morning. It's
too late now)

Post a reply to this message

> If you started a new thread, and gave a broad overview of all the different
> types of things that you're wanting your rendering package to do, then we could
> look at it and find some commonalities and propose some more generally
> applicable approaches.

This is very good idea !
I will think about it and share draft of API with you.

Post a reply to this message

So, I'll just post a few more thoughts here:

The file is big.   Huge, in fact.  33,642 lines of code.
All of it is hard-coded, and there's no easy way in POV-Ray or by importing the
file into a spreadsheet to work with the data.

Your primary data is the vertex location, its normal, and its pigment.
I would suggest writing those into a 2D array.

Then you loop through it and have a small amount of actual written code that
converts those all into the triangles of your mesh.

Better would be to convert that into a mesh2, which would further reduce the
amount of data, and likely address the color/normal mismatches.

I'd like to draw all of the normals for each vertex - but I really can't because
there's no data structure in the code.   It's all individual objects.

I can't really import it into a spreadsheet, because the data is all over the
place, and the indentation / leading text is all different.   If the data were
all collected /isolated on their own lines, I could possibly filter it all out.
The color data is on different lines than the vertex location and normal data.
Not a big deal - just a little more spreadsheet work.
But organizing that into an array declaration would put it all together nicely -
both "spatially" in the ASCII file, and (better yet) in a data structure that's
accessible to the user natively in SDL.  I can loop through it ALL, sort it,
compare it, graph it, use it to make normal arrows, etc.

If I were an end user of your utility, I'd probably desire such capability.

I might like to use the surface to illustrate a computer graphics textbook or a
calculus book, and show how the tangents and normals are calculated, buth
analytically and numerically.  I might want to label individual triangles,
highlight them, outline them, manipulate them as groups (triangles with shared
faces, triangles that share a common vertex, triangles in the same row or
column...).  And to do that, I'd need ready access to where the triangles are,
and the data that is used to create them.  If they were in arrays, I could
number them individually either by numbering them in the array at the outset,
using a counter, or by calculating column + (row*columns), I could also
calculate the min and max extents and use that to draw arrows, ... you get the
idea.

Your textures are all split up and hard coded as well.
If they were assigned as part of the triangle-making code, I could easily make
changes to the whole surface by adding a normal or a different finish to that
code, but there aren't many people who are going to want to recode 1600 smooth
triangles by hand.

I could even throw a branch into the loop, where #if (array index = "That one!")
then I could give it a highlight, outline, not render it, change the color,
texture, normal, finish, whatever.  I could alternate triangles based on
odd/even array index to give a sort of harlequin pattern, or choose odd/even of
the sum of x & z to give a checkerboard.  I can use the vertices as Voronoi
centers.  The mesh is not a closed mesh, so I can't use it in CSG.  If I knew
where the 4 corners were, I could just append 2 big triangles to the bottom.
Done.

Code is power.   That's why we're using computers - to handle digital data.
The current output is not much better than a hardcopy.  Yes, I can open the file
in POV-Ray and render it, but it's basically a static scene.

The more generalized a form that you store the raw data in, the more versatile
your scene file is, and the more useful it is to the end user, because they can
easily access and manipulate the data in a meaningful and easily understandable
way.

And that brings me to another way that you could approach this.
If your end users are going to be using POV-Ray anyway, why have MatLab export
all of the POV-Ray specific bits of scene code?

Why not just have MatLab export the DATA, and then write some macros in SDL that
will process the data into the forms that the user wants to render?

If you know the equation, then you can write that to a file in a way that people
can use it in an isosurface.  Or a parametric.  You have my scene file that
shows how to make it into a mesh.  I think I may have coded a mesh2 in the past.

Then you could write all that data into an include file, and simply let the
macros chew on the data in the include file in any way you or the end-user would
like.  Writing SDL code in MatLab so that MatLab can write the SDL code to and
SDL file just seems - like a lot of wholly unnecessary work.


But that's just my take.   You may have MatLab reasons for doing things a
certain specific way, but maybe there can be a whole lot of initial set-up work
that's completely avoidable - there's 30 years of scene files on this server -
and then you can start getting results, head right into testing, and spend that
90% of your time working on refinements rather than ascending from the beginning
of the learning curve.


- Bald Eagle out.

Post a reply to this message

Thanks a lot for a batch  of ideas, this is much more than was expected, when
I asked about surface rendering. I am glad that you not only assist me with
suggestions, but also provide a code that I can use with minimal modifications.

This is a huge support and really can save a lot of time for me, and at the same
time move the project forward much faster. Such collaboration inspires me to
work harder :)

Thanks to you, I am planning now to:

1. Put on the POV side (in macros) as much work as possible. I thought about it
at the start, but macros are a little bit tricky and I'v decided to postpone it
for the future. Now I see that the future has come :). As a first step I will
embed your code in a separate method that will replace present 'surf'.

2. Separate code and data for easely manual data manipulations if someone wants
to.

3. Find the best way for normals rendering.

4. Think about vertices/faces selection/highlight mechanics.

But now, as I had planned before, writing wrappers for basic POV entities and
creating example scenes for them.
And see that it's time to start a new thread :)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I'll just post a few more thoughts here:
>
> The file is big.   Huge, in fact.  33,642 lines of code.
> All of it is hard-coded, and there's no easy way in POV-Ray or by importing the
> file into a spreadsheet to work with the data.
>...

Hi

Have you not yet met Emacs?

  ;-)

See the attached zip-file.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

Attachments:
Download 'surface3_arrays_04.zip' (111 KB)

Hi, Tor.
>
> Have you not yet met Emacs?
>
>   ;-)

Already no, I leaved it about 10 years ago. )

> See the attached zip-file.
You are the wizard - what a beauty those normals !
Thanks a lot - this is another piece of code for embedding.

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Hi

Hi yourself.

> Have you not yet met Emacs?
>
>   ;-)

Nope.   I was raised in the American Public Education System, where we're
supposed to be just smart enough to read the names of the puppets that they
nominate every cycle, and not smart enough to undo the shackles and escape the
matrix.  As such, I still have certain  -  disabilities.

> See the attached zip-file.
>
> --
> Tor Olav

I had a feeling that Mr. Wizard would appear, with something out of his bag of
tricks.  :D

I truly do need to sit down and work with Emacs, Vim, awk, etc and figure out
how to do all the "word processing" tricks.

Thanks for being right there with a ready-made array example.

- BW

Post a reply to this message