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
for.

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)
adjustments.

* 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
origin".

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.
Distances.

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
vertex?
What is the bounding box of the selected object?
etc.

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
transforms.
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?
sorting?
uv-mapping?
corner fillets?
meshifying primitives?

Food for thought.

Post a reply to this message

Op 23/11/2022 om 13:31 schreef Bald Eagle:
> [snip]
> 
> 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.
> 
> [snip]
> 

This is good to read! All my wishes go to Chris and jr; theirs is not an 
easy one indeed.

Just for now, a very /basic/ wish for the new Moray, one that every 
Moray user will approve I am sure:


* Make the GUI /left-handed/ instead of /right-handed/. *

I need to plunge again into Moray after all those years, to recollect 
what were the advantages and disadvantages of the program, and what 
wishes I had at the time.

-- 
Thomas

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> 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
> for.
>
> 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.
> ...

as you probably know, C++ isn't one of "my" languages, so I'm in no position to
meaningfully comment on the code in the ways required for the above.  however, I
do think it a great idea to use this thread to bring together recollections and
opinions re using Moray, as TdG's reply (thanks Thomas) already shows, this
thread could grow to be a valuable resource.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > ...
> > 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
> > for.
> >
> > 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.
> > ...
>
> as you probably know, C++ isn't one of "my" languages, so I'm in no position to
> meaningfully comment on the code in the ways required for the above.  however, I
> do think it a great idea to use this thread to bring together recollections and
> opinions re using Moray, as TdG's reply (thanks Thomas) already shows, this
> thread could grow to be a valuable resource.
>
>
> regards, jr.
Good to see this discussion is at last getting results.
As a 'senior' user of this type of software, I have 30+ years experience of CAD
and related software in the engineering design industry. How many can remember
Autocad 1,2. v2.1 was the first usable version. I sometimes wonder how it ever
caught on.
Moray caught my attention (DOS) in that it was integrated with an excellent
renderer (POVRAY) and it could actually be used as a design tool as well as for
building scenes, etc.
As for features, I recall Moray had some parametric capabilities, I could build
assemblies with it that were dimensionally correct. This capability would be a
must as would 3D printing.
The UI was OK and usable and intuitive as such. Ease of use is essential without
gimmicks, all the benifits of CAD sftware is important.
I've ressurected a few old programs and managed to run them in WIN 10 64bit and
I am amazed at how marvellous they were, TrueSpace,Hexagon, Carrara to name a
few.
Please whatever you decide to do don't lose the magic of these programs.
I will pass on happy to know that this has been done.
Thanks for your efforts.

Post a reply to this message

As Bald Eagle said, meshifying primitives(and CSG combine) is a sugar feature in
my imagine in the past years when I use POV-Ray. But It can be regarded as an
extra- expect.


------------------------------------------------

My comments yesterday is like this:
If it can have a storage that collect "simple variable": like number, vector,
color, string, (not textures and objects) ..., then link to property of objects/
textures in the CSG-tree.

Just an imagine style of mine...

Post a reply to this message

Attachments:
Download 'variable table.png' (39 KB)

Preview of image 'variable table.png'

Thomas de Groot <tho### [at] degrootorg> wrote:

> Just for now, a very /basic/ wish for the new Moray, one that every
> Moray user will approve I am sure:
>
>
> * Make the GUI /left-handed/ instead of /right-handed/. *

I approve in the sense that I disapprove of locking the users into exactly the
opposite basis vectors.

If we would like to make the New Moray something useful and enduring, then I
would say that if all of the operations proceed from first principles, assuming
virtually nothing, then all of the operations can be generalized and it will be
as flexible and trouble-free as we can manage, possibly allowing things we might
not imagine when building it.

So I say, proceed from a configuration file or control panel, where the x, y,
and z vectors can be specified like in a matrix {}.  Then you can do whatever
you want.   Else, I can imagine the very first thing someone somewhere will
complain about is that they wanted to use Moray for something and - dammit - why
is it only LEFT handed???!  Can the developers make it so I can use it right
handed....?

Then we can see what Francois Le Coat does with it.  :D

Post a reply to this message

Then POV-Ray's function can be another table, I don't know how convenient such
type of program be implement, or very difficult? If check correct grammar is too
much demand...

Post a reply to this message

Attachments:
Download 'function table.png' (61 KB)

Preview of image 'function table.png'

"Convinced" <der### [at] gmailcom> wrote:

> As for features, I recall Moray had some parametric capabilities, I could build
> assemblies with it that were dimensionally correct. This capability would be a
> must as would 3D printing.

I would concur, as specifying exact parameters is crucial for precision work,
and using POV-Ray to model or design real and/or important things that are not
simply arbitrary and artistic in purpose.

With regard to 3D printing, I was flirting with the idea of working for a local
rapid prototyping company doing CNC, and for me at least, designing things in
POV-Ray or OpenSCAD seemed only one small step removed from writing G-code for
CNC machining.  A module to translate G-code commands to difference {} or even
animation would be a possibility to be aware of and leave open.
I say that, not to be ridiculous, but because one never knows who will become
interested in Moray, and by extension, POV-Ray - that could lead to more
widespread use, along with technical and financial support.

> The UI was OK and usable and intuitive as such. Ease of use is essential without
> gimmicks, all the benifits of CAD sftware is important.
> I've ressurected a few old programs and managed to run them in WIN 10 64bit and
> I am amazed at how marvellous they were, TrueSpace,Hexagon, Carrara to name a
> few.
> Please whatever you decide to do don't lose the magic of these programs.

I would love to see some examples / screenshots of what those programs do.

I have no idea how Moray was put together, but I think that the Linux users here
would probably agree that emulating the "Unix mindset" - writing a standalone
tool that does one thing, and one thing well - and then daisy-chaining those
tools together might be the best approach.

I'm reminded of analyses of what NASA did with the space shuttle and other
projects, where they transitioned from designing modules with individual
specifications, developed by separate teams assigned to those parts, and those
were then interfaced with each other to make a working whole.   Then they
switched to that whole "everything is integrated as a whole" and there was no
localized control or separability.  Every time something at one end got changed
- it affected what some other team was doing somewhere else. (Boy, does this
bring to mind Bezier splines and NURBS)

So I think that just as important as what "we" _should_ do, is what we _should
not_ do, if at all possible.   I recall clipka going through sections of code
and not having any idea what the person who wrote that part was thinking.  (uv
mapping modes)
Separable tasks were integrated into the parser, making them difficult to factor
out, if not impossible without a full from-the-ground-up rewrite.

And lastly, just have a text file associated with any modules or files or
functions or macros for the developer to just scribble in.   "Here's what I'm
thinking and WHY - here's where these numbers / formulas / methods come from,
here are the references and excerpts, WIP code snippets, etc....

Post a reply to this message

Attachments:
Download 'prototekpart.png' (174 KB)

Preview of image 'prototekpart.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
> > Just for now, a very /basic/ wish for the new Moray, one that every
> > Moray user will approve I am sure:
> >
> >
> > * Make the GUI /left-handed/ instead of /right-handed/. *
>
> I approve in the sense that I disapprove of locking the users into exactly the
> opposite basis vectors.
>
> If we would like to make the New Moray something useful and enduring, then I
> would say that if all of the operations proceed from first principles, assuming
> virtually nothing, then all of the operations can be generalized and it will be
> as flexible and trouble-free as we can manage, possibly allowing things we might
> not imagine when building it.
>
> So I say, proceed from a configuration file or control panel, where the x, y,
> and z vectors can be specified like in a matrix {}.  Then you can do whatever
> you want.   Else, I can imagine the very first thing someone somewhere will
> complain about is that they wanted to use Moray for something and - dammit - why
> is it only LEFT handed???!  Can the developers make it so I can use it right
> handed....?
>
> Then we can see what Francois Le Coat does with it.  :D

Reserve left-hand/ right-hand is better indeed.

I cannot figure out what is "where the x, y, and z vectors can be specified like
in a matrix {}"

Post a reply to this message

"And" <49341109@ntnu.edu.tw> wrote:

> I cannot figure out what is "where the x, y, and z vectors can be specified like
> in a matrix {}"

When we use POV-Ray, we assume that the basis vectors for the Euclidian space we
are modeling in, are defined as:
x = <1, 0, 0>
y = <0, 1, 0>
z = <0, 0, 1>

TdG points out that a "fix" or workaround for scenes made in Moray, which is
right-handed, is to scale the camera "scale <-1, 0, 0>" in order to "flip" the
whole scene and make it look correct.

But fundamentally, what you are doing is changing the x basis vector (relatively
speaking), which affects every point in the 3D space that you are working in,
and therefore every object built using those coordinates.

Making those basis vectors user-definable at their core would add a maximum
flexibility.
In fact, if one really wanted to go nuts, rather than just having scalar values
in the matrix, one could define some sort of function to warp the entire
coordinate space.   I know that sounds crazy, and most people will ask, "WHY
would you want to do that???!", but watch Grant's excellent videos, and you
might get some ideas.


http://www.f-lohmueller.de/pov_tut/trans/trans_400e.htm

Also check out Grant Sanderson's (3Blue1Brown) excellent series on linear
algebra.
https://www.youtube.com/watch?v=k7RM-ot2NWY

Post a reply to this message