POV-Ray : Newsgroups : povray.general : PigeonTalk : Re: PigeonTalk Server Time
20 Apr 2024 01:40:11 EDT (-0400)
  Re: PigeonTalk  
From: Bald Eagle
Date: 5 Feb 2022 08:45:00
Message: <web.61fe7e98f706e4651f9dae3025979125@news.povray.org>
David Buck <dav### [at] simberoncom> wrote:

> I'm also using it as a way to explore new programming paradigms.  I want
> to get away from programming as a text-based activity.  We've come so
> far in computing that we shouldn't need to restrict ourselves to text
> editors and compilers in order to write our programs. Programs are built
> on concepts.  Let's find a say to visualize those concepts and edit the
> visualizations. We need better tools.

We do, and there has been extensive discussion over the years of what those
tools are and how they should function.

Certainly there are tasks that are easiest and most intuitive to accomplish or
create the vast majority of the basic rough framework using some sort of
modeler.

https://agalena.nfshost.com/b1/software/epspline-prism-and-lathe-editor/
Moray

There are, however, other tasks that are best accomplished with that sort of
hand-coding approach.  Off the top of my head, this is usually along the lines
of finding intersections, tangent points, angles, etc in order to make things
line up or transition smoothly.

Dick Balaska's qtpovray editor has some interesting features slong the lines of
what you're talking about.
http://buckosoft.com/qtpov/
Check out the color and colormap editors - hovering over that codeblock displays
a "tool tip" as a visual guide.


>  From a POV-Ray point of view, imagine a scene editor where a plane or a
> sphere is shown as a block (look at Scratch or Blockly) using an icon of
> a plane or a sphere? What if a texture block could show a small sphere
> rendered in that texture? What if a color value showed a square with
> that color? What if a camera definition could show a simple scene from
> that perspective? A light source could show you a simple scene rendered
> from the location of the light source?  Would that make it easier to
> look at your SDL script and understand what's going on?

I know most folks haven't ever used VISIO, but I have found it to be a versatile
and easy-to-use drawing program primarily because it has a lot of the types of
features that you're discussing.  Each shape has a default template that you
grab, drag, and drop onto a worksheet, can resize and reposition with handles,
align by mouse, or snap-to grids, evenly distribute many objects across a space,
or directly edit the numerical location by hand.   Colors textures and borders
can be applied as attributes.

The really interesting thing, of course, are the "shape sheets" that each
instantiation of a shape has.   It's like an embedded spreadsheet that you can
edit to control the behaviour of the shape.   Maybe you want a rectangular shape
to automatically display the angle of the diagonal.  Maybe you want to lock the
vertical size so that it can only be resized horizontally.   Maybe it needs to
stay a square, and you can only resize it diagonally.

Probably the easiest way to get an idea is to check out
http://www.visguy.com/
and the projects that people in the discussion forum work on.

I know that when I first began applying myself to using POV-Ray, it was the
inability to quickly and properly visualize the vector space and the objects
that I was placing into it that really made things slow, and increased the entry
barrier.  The instant-feedback and interaction with a modeler - especially on
with some sort of "meta" view - showing where the camera is in the scene - is
something that I really think helps people grasp those concepts and have those
critical "AHA!" moments that keep them going so that they can get up the
momentum to KEEP using something like POV-Ray.

Then it become less of "I'll NEVER be able to do.... xyz" because they already
have a list of _fait accomplis_ to look back.   Nothing inspires more confidence
than success.



> I'm excited by where this could go.  I hope others can share in that
> excitement.

I know that when I first started programming - first with a TRS-80, and then
with the various home computers that started to become available (Timex Sinclair
1000, VIC-20, Commodore 64, Atari XL-800, ....) it was the ability to draw,
animate, and control input with a controller (joystick) or output via the
joystick port (analog-to-digital converter and vice-versa) that made the system
interactive enough to provide that enduring "hook" - something that kept that
interest and passion alive and fresh during the inevitable rough spots - that
really made it exciting.  What kid didn't want to write their very own video
game?   (I know, millions - but they don't count here   ;)  )

Arduino has certainly caught on in a huge way, and it certainly allows Chris
Young to still get along and be employed doing important and productive
electronic and software development work.



I'm sure you have your own ideas about what this will do and where it will go,
but in my attempt to move ahead with certain projects, the thing that I have
found to be the most limiting is the lack of "under the hood" functionality in
terms of functions and subroutines.
Things like various types of sort, convex hull, and other stuff that one might
find in libraries, computer science courses, and things one sees being coded in
live-coding videos.


- Bill


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.