re p.text.scene-files.

Post a reply to this message

Attachments:
Download 'flimg.png' (263 KB)

Preview of image 'flimg.png'

"jr" <cre### [at] gmailcom> wrote:
> re p.text.scene-files.

I have played with this stuff many many times over the years.
And for new users, this stuff is really nice.
I'm glad you brought this out and updated a classic FL POV-Ray tool.

Just from memory, I would say that you may want to introduce some switches to
adjust things, and maybe have your ruled surfaces and axes adjustable.
Add no_shadow to the axes.

Maybe have a proper scene that uses this as an include file - commenting out the
#include statement then shuts the whole thing off.

Sometimes I want axes, sometimes I just want a reference sphere for the origin.
For most modeling in POV-Ray, people tend to model AT the origin.  So, you may
want to incorporate transparency for the "paper" of the "graph" so that you can
see below y=0 but still have the grid at y=0.  An emissive texture would help
seeing the lines - and might look really sharp.  :)

It's nicely done, and something that I thought I would have surely used more -
but for some reason I don't?


Not sure how much you want to play around with this, but here are just some
thoughts:

I find that too many parameters just makes it too hard to use. (Me)
Maybe if you just have a single "extent" variable for the x and z dimensions,
you could copy those into the offsets of the two vertical planes.
Parameterize the radius of the arrows (before the merge) and make your cones a
formula based on that.
Make it so the plane doesn't clip off the z-arrowhead.

As a new user, dealing with POV-Ray's left-handed coordinate system could be a
real mind-bender.  Not to mention translation / rotation relative to the origin.

Perhaps:
label the axes
provide rotational indicators to show what a rotation around +x looks like
(use a partial torus as an arrow)

A whole 'nother way of graphing based on radius and degrees or radians would be
helpful for those doing that sort of work as well.

I can recall struggling with all of this ...somewhere around 2013, so I'm sure I
have a lot of stoopid noob posts on things I just didn't understand, and I'm
sure I posted a whole laundry list of scene development tools that I may or may
not have written and have lying around somewhere - including this exact scene
layout space.

I can see if I can dig them up if you'd like.

Provide a (switchable) quick reference debug stream output so that users just
starting to use any additional tools or options can see it right in the output
from the render and not have to switch windows or tabs...

I'll stop now, or I could go on forever.   "Mission creep" is a killer.


Excellent work, Number 14!


Be seeing you.   ;)

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > re p.text.scene-files.
>
> I have played with this stuff many many times over the years.
> And for new users, this stuff is really nice.
> I'm glad you brought this out and updated a classic FL POV-Ray tool.
>
> Just from memory, I would say that you may want to introduce some switches to
> adjust things, and maybe have your ruled surfaces and axes adjustable.
> Add no_shadow to the axes.

fact is I deleted the (usual) 'no_shadow' because the image is meant to look (a
little) like FL's "squared background" image, where the Y-axis casts a shadow.
:-)

more below.

> ...
> Sometimes I want axes, sometimes I just want a reference sphere for the origin.
> For most modeling in POV-Ray, people tend to model AT the origin.  So, you may
> want to incorporate transparency for the "paper" of the "graph" so that you can
> see below y=0 but still have the grid at y=0.  An emissive texture would help
> seeing the lines - and might look really sharp.  :)

transparency - check.  "emissive" is a v good idea, should make the lines stand
out better.  thanks.

also works with image_map pigments, see attached.

> ...
> I find that too many parameters just makes it too hard to use. (Me)
> Maybe if you just have a single "extent" variable for the x and z dimensions,
> you could copy those into the offsets of the two vertical planes.
> Parameterize the radius of the arrows (before the merge) and make your cones a
> formula based on that.

only two parameters are needed to include a "graph paper" in a scene.  the
plane's orientation and the offset from origin, all other "knobs" have defaults
to make the plane look similar to FL's original, out of the box.

> Make it so the plane doesn't clip off the z-arrowhead.

yep, coincident surfaces.  :-)

> As a new user, dealing with POV-Ray's left-handed coordinate system could be a
> real mind-bender.  Not to mention translation / rotation relative to the origin.
> Perhaps:
> label the axes

also a good point.  will think about how that could be incorporated to "fit".

> ...
> A whole 'nother way of graphing based on radius and degrees or radians would be
> helpful for those doing that sort of work as well.

not useful for 'Ruled()' I think, however, interesting, what do you have in
mind?

> ...
> Provide a (switchable) quick reference debug stream output so that users just
> starting to use any additional tools or options can see it right in the output
> from the render and not have to switch windows or tabs...

not sure what sort of message would be useful feedback from the macro.

> I'll stop now, or I could go on forever.   "Mission creep" is a killer.

;-)

> Excellent work, Number 14!
> Be seeing you.   ;)


regards, jr.

Post a reply to this message

Attachments:
Download 'ruled_img.png' (455 KB)

Preview of image 'ruled_img.png'

"jr" <cre### [at] gmailcom> wrote:

> > A whole 'nother way of graphing based on radius and degrees or radians would be
> > helpful for those doing that sort of work as well.
>
> not useful for 'Ruled()' I think, however, interesting, what do you have in
> mind?

See attached

Post a reply to this message

Attachments:
Download 'polar_plot(2).jpg' (97 KB)

Preview of image 'polar_plot(2).jpg'

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > A whole 'nother way of graphing based on radius and degrees or radians would be
> > > helpful for those doing that sort of work as well.
> >
> > not useful for 'Ruled()' I think, however, interesting, what do you have in
> > mind?
>
> See attached

interesting, not seen "graph paper" like that before.  are there other types?
if yes might be worth putting together a "package".


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> interesting, not seen "graph paper" like that before.  are there other types?
> if yes might be worth putting together a "package".

Lots.

Role Playing Games often use hexagonal paper.
Any tesselation will work.
Ternary plots
https://en.wikipedia.org/wiki/Ternary_plot

etc.

Post a reply to this message