POV-Ray : Newsgroups : moray.win : Impending Moray Source Release : Impending Moray Source Release Server Time
10 Dec 2023 10:02:17 EST (-0500)
  Impending Moray Source Release  
From: Bald Eagle
Date: 23 Nov 2022 07:35:00
Message: <web.637e12921fc0f0961f9dae3025979125@news.povray.org>
While Chris and jr are sifting through and untangling all of the distasteful
"intellectual property" issues, I thought it would be a good idea to start a new
thread where:

Chris and jr could discuss some of the things that they've found in the "SO MANY
FILES!!!" that people with coding experience can begin to think about and plan

Also, past and current users can discuss, explain, or preferably just _list_ in
as concise a manner as possible, what they perceive as the specific advantages
and disadvantages of the GUI, and any bugs or limitations that they have
experienced while using the software.

I have only the vaguest recollection of using Moray for something, and honestly
can't accurately recall when, where, or for what - but it could have been in
2014 .... or in early 2000's.

As such, I can presently do no more than speculate, but I can imagine that after
some files are edited or redacted do to "licenses" for ancient code libraries,
that the core software will need and extensive rewrite.   Hopefully there will
be enough "fair use" divulging of any national security secrets - or the
equivalent pseudo-code to piece it all together and get it work, and we can not
dig ourselves into the same hole where we are forever beholden to seeking the
permission of others.

Anyway, the point here is, when people with the requisite skill set begin
building a new version of Moray, it might be helpful to them to have a list of
features / usage philosophy to guide them in the initial structuring and coding
so that they don't have to suddenly go back and restructure / refactor
everything to make the code be able to handle some important, yet unrecognized
to them feature.

My conception of a good drawing/modeling program, is along the lines of CAD/CAM
software, or (as jr can attest) VISIO.  The scene elements can be put onto the
screen in a very quick and dirty fashion, but then, I think, the key is that
everything can then be further refined with manual (text input / scripts)

* This is not a list of demands, on my part, but rather me thinking out loud to
illustrate to developers what end-users may want, and show all of the
more-than-eager end users just how much work may be required to give them even
"the smallest" of desired features.  "All you gotta do is..."   ;)

This is likely hard to explain, so I can provide a few examples, and others can
chime in.

Lets suppose I want to draw two cubes, rotate them so that their diagonally
opposing corners lay along the x-axis, and they then touch at exactly their
corner vertices.

I think that being able to select / deselect certain features like corner
vertices and align them with other features in the scene will be of paramount
importance.  Good software that I've used features "snap & glue", "align to
grid", "evenly space/distribute", rotate, and other ease-of-use tools.

So maybe I draw a cube, select two opposing corners on one, click "align with
x-axis", copy it, paste a new cube, and then drag the new cube over until it
snaps, and perhaps glues (union) to the first cube.
Now I decide that want one or both of the cubes to be larger.  But they still
need to have their corner vertices joined, and that point remain stationary. So
the cubes need to get scaled, but with that corner vertex being the "local

All of this needs to deal with transformation matrices and key reference points
in the primitives (handles), all the while being reasonably fast and seamless to
the user.

Because really, all a modeler is doing is pre-coding all of things that you
don't know how to code yourself, and displaying the result in as close to
real-time as possible.

Now one of the things that I REALLY like about good software packages is that
they give a lot of feedback and allow a lot of options and interaction from/with
the user.   Readouts to n decimal places that can be hand-edited.  Angles.

What are the <x,y,z> coordinates of that shared corner vertex?
What is the angle between the x-axis and one of the edges?   One of the faces?
How far away is that shared vertex from the camera?   From the opposing corner
What is the bounding box of the selected object?

I guess what I'm trying to sort out, for myself, is what is a whole nested
CSG-tree going to look like, and how do we go about exploring all the little
parts of that and performing specific tasks?

And finally, what can/should the SDL output file look like?

I personally love multiple ways to do, use, display, and store things, so maybe
I'd like an extremely complex and verbose SDL file - because I'm using it to
learn / explain something, and want all my objects handled with matrix
Other people may just want the shortest, tightest code they can get, and just
want objects defined with "magic numbers" that there will never be any hope of
determining where they came from or why.

Do we have "undo / redo"?  To how many levels?   How much memory does that take?
What other modeling things have we discussed / wanted in the past that code
modules will have to be written for?
convex hull?
corner fillets?
meshifying primitives?

Food for thought.

Post a reply to this message

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