"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'