 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > ...
> > So now I very much regret that I didn't look into Python earlier.
> ...
> re Python, does "sed -e 's#^I# #g' -i *.py" still work for newer versions of the
> language ?! :-)
might be perceived .. rude. but that, really, is not intended. I do think that
'make', when conceived, ought not to have made its functioning dependent on an
"invisible" (ie 0x09) character. and I cannot understand to this day why, with
that "experience" in mind, someone would want to design a new, "system-level"
even, language which relies (relied?) on the same not-visible control character.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Are you thinking of sorting and collecting all the vertices into
> a list of unique vertices ?
>
> If so, it would be an interesting challenge to simultaneously
> rearrange the colors and the normal vectors so that they are ordered
> correspondingly (or respectively ?) in their own lists.
Well, the idea was, given the "point cloud", and the fact that it's obviously
generated in a grid layout, then I should be able to sort by multiple fields -
x, then z. That would all go into a 2D array. And yes, the normals and colors
would go into the same array.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> I think it would be better if your Matlab code created the arrays
> containing the vectors directly, like this:
>
> #declare VV =
> array[N][3] {
> { <3.43, 7.67, 1.83>, <3.76, 7.67, 1.63>, <3.76, 8.00, 1.13> },
> ...
> }
> ;
> #declare NN =
> array[N][3] {
> { <0.32, 0.72, 0.62>, <0.36, 0.74, 0.56>, <0.37, 0.78, 0.51> },
> ...
> }
> ;
> #declare Colors =
> array[N][3] {
> { <0.43, 1.00, 0.00>, <0.48, 1.00, 0.00>, <0.62, 1.00, 0.00> },
> ...
> }
> ;
I would go one step further, and put them all into the same array, although
that's not strictly necessary. I'm just thinking about juggling all of the
data in a macro, and having a single array name would make it easier, but not
really necessary.
But also, depending on what other people might want to do with the data, if it
were a [N][9] array, then the ASCII format would lend itself to importing into a
spreadsheet and keeping all of that data together. It would also be together
in the ASCII SDL/inc file, so that it would be easy to read and think about,
rather than hunting through 3 arrays. Making it a [N][10] array would allow
numbering of the vertices as well, and for the same easy-reading purpose.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I would go one step further, and put them all into the same array, although
> that's not strictly necessary. I'm just thinking about juggling all of the
> data in a macro, and having a single array name would make it easier, but not
> really necessary.
That's what I've done, thanks to your examples, result attached.
Post a reply to this message
Attachments:
Download 'surface3_make_mesh.pov.txt' (931 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"yesbird" <nomail@nomail> wrote:
> Hi, guys.
> May be am asking too many questions, but I am new to POV and before asking
> trying everything I can not for only one hour.
>
> Could you suggest the way of getting rid of artifact, markered on this image,
I knew this was going to be a debugging nightmare, so I made a nice big Gin &
Tonic, got out the Italian olive medley, and started fiddling.
I have found out what your problem is, and it's directly related to what MatLab
exports, and how you're trying to render it in POV-Ray.
At first glance, it sort of seemed to me that some of the colors were getting
"dragged" up into places that they shouldn't be. And that's sort of what's
happening. I outlined each triangle to show the edges, and there was a
pronounced matching of the colors with the edges of the grid - parabolas of
color that followed the vertical slicing of the surface.
What you WANT is a nice, gradient y pattern like I first suggested.
What you're getting is a 3-color interpolation of the 3 vertex colors, which is
blending colors from the wrong regions, and thus giving you the funny colors.
What I did was "shrink" the triangles a bit, and plot spheres with the vertex
colors at each vertex. Then I made a cylinder with a gradient going from the
color of one vertex to the color of the other vertex. Then I did the same
thing, only connecting all of the vertices to the triangle's center.
This shows the geometry and the colors along with the way the colors are
interpolated.
_I think you can fix this by changing the axes that you're slicing along._
I would also suggest that you orient all of you stuff the way POV-Ray does -
with a left-handed coordinate system, +x to the right, +y as up, and +z going
into the screen and away from you.
- BE
Post a reply to this message
Attachments:
Download 'surface3_checkattributes.png' (694 KB)
Preview of image 'surface3_checkattributes.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"yesbird" <nomail@nomail> wrote:
> > I would go one step further, and put them all into the same array, although
> > that's not strictly necessary. I'm just thinking about juggling all of the
> > data in a macro, and having a single array name would make it easier, but not
> > really necessary.
>
> That's what I've done, thanks to your examples, result attached.
I'm sorry to say, but I don't think that this is a sound advise.
Have a look at these two ways of organizing, naming and declaring the data:
// ====================================================================
#declare V = array[4802][9] {
{<3.76, 7.35, 2.01>, <3.76, 7.67, 1.63>, <4.08, 7.67, 1.39>, <0.32, 0.64, 0.70>,
<0.36, 0.74, 0.56>, <0.40, 0.76, 0.52>, <0.38, 1.00, 0.00>, <0.48, 1.00, 0.00>,
<0.55, 1.00, 0.00>},
{<3.76, 7.35, 2.01>, <4.08, 7.35, 1.83>, <4.08, 7.67, 1.39>, <0.32, 0.64, 0.70>,
<0.38, 0.69, 0.62>, <0.40, 0.76, 0.52>, <0.38, 1.00, 0.00>, <0.43, 1.00, 0.00>,
<0.55, 1.00, 0.00>},
....
}
// ====================================================================
// 50x50 Vertices --> 2x49x49 triangles
#declare M = 2*(50 - 1)*(50 - 1);
// Triangle data
#declare VV = array[M][3]; // Vertices
#declare NN = array[M][3]; // Normals at the vertices
#declare Colors = array[M][3]; // Colors at the vertices
#declare VV =
array[M][3] {
{ <3.76, 7.35, 2.01>, <3.76, 7.67, 1.63>, <4.08, 7.67, 1.39> },
{ <3.76, 7.35, 2.01>, <4.08, 7.35, 1.83>, <4.08, 7.67, 1.39> },
...
}
;
#declare NN =
array[M][3] {
{ <0.32, 0.64, 0.70>, <0.36, 0.74, 0.56>, <0.40, 0.76, 0.52> },
{ <0.32, 0.64, 0.70>, <0.38, 0.69, 0.62>, <0.40, 0.76, 0.52> },
...
}
;
#declare Colors =
array[M][3] {
{ <0.38, 1.00, 0.00>, <0.48, 1.00, 0.00>, <0.55, 1.00, 0.00> },
{ <0.38, 1.00, 0.00>, <0.43, 1.00, 0.00>, <0.55, 1.00, 0.00> },
...
}
;
// ====================================================================
Which one do you think informs a new user best about what is going on ?
I don't think that it should be a goal in this case to write minimal
code and packing things as tightly together as possible.
Giving names to different sections of data should be part of the
documentation.
Magic numbers like 4802 is never a good thing. You should show the user
how you ended up with that number.
If everything is put into a single array, then if someone wants to
recalculate e.g. the normals, they may have to deal with the vertices
and the colors too.
I myself have been abusing Excel for many years to process data that
would have been much better dealt with in a high level programming
language. So I don't think that making it easier to import all the
data in one go into a spreadsheet justifies anonymising and obscuring
the data even more than they already are.
I apologize if this sounds a bit harsh, but I am writing this with my
best intentions.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "yesbird" <nomail@nomail> wrote:
> > Hi, guys.
> > May be am asking too many questions, but I am new to POV and before asking
> > trying everything I can not for only one hour.
> >
> > Could you suggest the way of getting rid of artifact, markered on this image,
>
>
>
> I knew this was going to be a debugging nightmare, so I made a nice big Gin &
> Tonic, got out the Italian olive medley, and started fiddling.
>
>
> I have found out what your problem is, and it's directly related to what MatLab
> exports, and how you're trying to render it in POV-Ray.
>
> At first glance, it sort of seemed to me that some of the colors were getting
> "dragged" up into places that they shouldn't be. And that's sort of what's
> happening. I outlined each triangle to show the edges, and there was a
> pronounced matching of the colors with the edges of the grid - parabolas of
> color that followed the vertical slicing of the surface.
>
> What you WANT is a nice, gradient y pattern like I first suggested.
> What you're getting is a 3-color interpolation of the 3 vertex colors, which is
> blending colors from the wrong regions, and thus giving you the funny colors.
>
> What I did was "shrink" the triangles a bit, and plot spheres with the vertex
> colors at each vertex. Then I made a cylinder with a gradient going from the
> color of one vertex to the color of the other vertex. Then I did the same
> thing, only connecting all of the vertices to the triangle's center.
>
> This shows the geometry and the colors along with the way the colors are
> interpolated.
>...
Yes, I think you have found the reason for the artifacts. Good job!
Here's a web page about how to deal with this:
"How to blend colors across 2 triangles"
https://webglfundamentals.org/webgl/lessons/
webgl-qna-how-to-blend-colors-across-2-triangles.html
Nice image btw.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Which one do you think informs a new user best about what is going on ?
THIS ONE! THIS ONE! :D
#declare V = array[4802][9] {
// VERTEX1 NORMAL1 VERTEX2 NORMAL2 VERTEX3 NORMAL3 COLOR1
COLOR2 COLOR3
{<-8.00, -8.00, -1.51>, <+0.19, +0.19, +0.96>, <-8.00, -7.67, -1.62>, <+0.07,
+0.07, +1.00>, <-7.67, -7.67, -1.64>, <-0.06, -0.06, +1.00> <1.00, 0.66, 0.00>,
<1.00, 0.61, 0.00>, <1.00, 0.61, 0.00>}
> I don't think that it should be a goal in this case to write minimal
> code and packing things as tightly together as possible.
>
> Giving names to different sections of data should be part of the
> documentation.
It should, and If someone like me wants to look at it in a spreadsheet, then I
could just regurgitate it out into a #debug file and do it that way.
> Magic numbers like 4802 is never a good thing. You should show the user
> how you ended up with that number.
I'd agree, as it also helps when writing the code for loops, etc.
As much math as I do, I can never seem to get the really simple stuff right.
>
> If everything is put into a single array, then if someone wants to
> recalculate e.g. the normals, they may have to deal with the vertices
> and the colors too.
The first thing I did was recalculate the normals, and
a) you are right, it was confusing at first, because there were no labels, and I
forgot the alternating structure of the smooth_triangle format.
b) it was still pretty easy since I just made a smaller array of the new
normals, and used a modified macro to make the mesh with the new normals from
the new array.
> I myself have been abusing Excel for many years
OMG. There's help out there, Tor. I hear there's even some groups that can
wean you off of that with OpenOffice. ;)
> I apologize if this sounds a bit harsh, but I am writing this with my
> best intentions.
We're all just here to learn and play. Don't go full Ive, and I'm sure
everything will be ok :D
- Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Also:
I've been casually wondering, "Why is this guy from Russia using "yesbird" as a
username?"
And then I see the YesShows album cover! WooHoo!
As jr would say, "I'm chuffed!"
Yes is easily at the top of the list of my favorite bands of all time.
I think a Yes themed POV-Ray render is going to have to be one of my next
non-math doodles.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I knew this was going to be a debugging nightmare, so I made a nice big Gin &
> Tonic, got out the Italian olive medley, and started fiddling.
If I could, I'd buy them for you )
> I have found out what your problem is, and it's directly related to what MatLab
> exports, and how you're trying to render it in POV-Ray.
>
It was a serious investigation, so I am a little ashamed that my question forced
you to do so much work.
> _I think you can fix this by changing the axes that you're slicing along._
Many thanks ! Now know where to look to fix it. In any case I decided to follow
your suggestion and do all calculations in POV, passing only function or mesh,
described surface, using yours and Tor's code, leaving present implementation as
alternative.
>THIS ONE! THIS ONE! :D
>#declare V = array[4802][9] {
>// VERTEX1 NORMAL1 VERTEX2 NORMAL2 VERTEX3 NORMAL3 COLOR1
COLOR2 COLOR3
Sorry, I missed it, assumed, that macro code is transparent and hence structure
is 'self-explained'.
> I would also suggest that you orient all of you stuff the way POV-Ray does -
> with a left-handed coordinate system, +x to the right, +y as up, and +z going
> into the screen and away from you.
I only want to make it compatible with ML's defaults and render from the same
viewpoint as it does.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
