|
 |
> 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.
Unbelievable ! I didn't expected to find yesfun here, on 3D math forum. I am mad
about Yes and Roger Dean from schooldays and even trying to follow his style. My
dream-of-the-life is making full-format 3D animation by "Tales from Topographic
Oceans" with original music.
Although I am mastering ZBrush and Cinema4D, the amount of work is frightens me,
and I am stopped at simple 2D sprite animations:
https://yesbird.ru/
>
> I think a Yes themed POV-Ray render is going to have to be one of my next
> non-math doodles.
>
Making RD-like images with POV sound very interesting, may be some images from
my archive will inspire you for this feat:
https://drive.google.com/file/d/1jkq5-iT88QdkPPtHoOZztfcBuw-ku_3w/view?usp=sharing
Please keep me informed, I would like to see even intermediate results.
Post a reply to this message
Attachments:
Download 'talestopooriginal1920x1200.jpg' (900 KB)
Preview of image 'talestopooriginal1920x1200.jpg'
|
|
|
|
Hi Sergey,
"yesbird" <nomail@nomail> wrote:
> It was a serious investigation, so I am a little ashamed that my question forced
> you to do so much work.
Well, it was a challenge to figure out what to do, for sure. I was sitting
there staring at 4,802 vector entries in OpenOffice, thinking "How the
Fu....nction am I going to figure out if all of the adjacencies match up...?"
And then I outlined the triangles, which were arranged in a different manner
than I had expected, and got the idea to slightly separate them, and then put
colored spheres on, but singce they'd overlap, I had to "shrink" the corner
vector in toward the center.
Then I thought that maybe there was some kind of color-averaging that gave a
middle-gray in the middle of the interpolation, so I put the spheres in the
centers and connected with lines -
which showed that the problem if the vertices, and nothing in a spreadsheet or
evaluating adjacencies would have revealed anything anomalous - it's definitely
something that I needed to see.
Anyway, it makes for a good rule of thumb - "always slice meshes parallel to the
texture gradient". :)
> > _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.
Indeed. I am a big fan of plenty of redundant options.
Just a few thoughts I had while cramming dirty pallet shrinkwrap into the
hydraulic compactor:
Matlab probably has a lot of routines that allow the user to manipulate
arbitrary data in ways that POV-Ray currently cannot. Data that has no equation
that it's derived from. Random points, measurement data, statistics, etc.
(It would be great of we had linear regression, and singular value decomposition
/ principal component analysis ... I'm working on it)
Also, I'm curious as to what a VERY large "3D" thing would look like in MatLab -
something that extends deep into the screen. It likely uses simple raster
graphics - whereas POV-Ray does things in "actual 3D", so the farther away it
gets, the smaller it gets - until it's less than a single pixel wide/high.
One final thing that most might not consider as a pertinent issue:
POV-Ray is open source, which means that anything that gets done in "POV space"
is freely available to anyone, "forever".
Considering the state of the world and the censorship and deplatforming and
corporate hijinks going on, it might be best to preserve as much accessibilty to
the data and the ability to manipulate and render it as possible, purely for
those reasons.
When will Matlab get bought by the WEF or infiltrated by "them"? You could lose
your Matlab license, they could change the code, change the interface, change
the output, write the output in binary, or proprietary encrypted format, or put
spyware into their code package such that you'd rather not use it anymore.
Laugh all you want, but... I'll start working on that tin-foil texture.
> >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'.
It is, of course, but I stumble blindly through most of these projects and
usually need some sort of Braille guideposts. :P
> > 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.
Understood. It's pretty typical to convert scenes modeled in Moray or other
software packages that have different coordinate systems to POV-Ray - usually
using a transform {} matrix on the scene or the camera.
When most everything is worked out and running, it probably won't be that big of
a deal, but for debugging sanity, it might be worth putting labeled axes in the
scene, and defining the transform matrix at the top of the scene, with a few
lines of comments describing exactly what it does and why it's there.
Happy rendering,
- Bill
Post a reply to this message
|
|
|
|
> Anyway, it makes for a good rule of thumb - "always slice meshes parallel to the
> texture gradient". :)
Well said ! :)
> Matlab probably has a lot of routines that allow the user to manipulate
> arbitrary data in ways that POV-Ray currently cannot. Data that has no equation
> that it's derived from. Random points, measurement data, statistics, etc.
Yes, this is the case when we can pass data, not formulas and POV will do the
rest.
> Also, I'm curious as to what a VERY large "3D" thing would look like in MatLab -
> something that extends deep into the screen.
I have experience working with Point Cloud toolbox and it was a sad experience -
works too slow, visualization is poor.
> One final thing that most might not consider as a pertinent issue:
> ...
> Laugh all you want, but... I'll start working on that tin-foil texture.
Not so funny as it could be at least 10 years ago :(. I thought about all this
things before start sticking to ML, and know that there is some risk here.
This is the reason, why I am prefer R for some of my projects and trying to
separate SDL code from ML as much as possible for easely porting it to R in
future, using the same *.inc called from different language.
> When most everything is worked out and running, it probably won't be that big of
> a deal, but for debugging sanity, it might be worth putting labeled axes in the
> scene, and defining the transform matrix at the top of the scene, with a few
> lines of comments describing exactly what it does and why it's there.
You are right - accepted )
--
YB
Post a reply to this message
|
|
