 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscape net> wrote:
> "ingo" <nomail@nomail> wrote:
> > object and material are just containers, lists/arrays..
> > there are a few specialised ordered lists with an operator attached, union,
> > intersect etc.
> >
> > A povObject/shape is like a specific composed dictionary/struct/record as is
> > texture. One could define it all in SQLite:
>
> > etc. etc. who needs type-systems and OOP if you have a database ;)
@ingo. very happily second that. </grin>
too, I think, organising the design around a db(ms) internally will make for
less complexity in the VM backend, and perhaps elsewhere (like providing the
"introspection" BE mentions to "the front").
> ...
> It would also be great if as many things as possible had some sort of default
> attached to it, so I could just invoke a sphere, and maybe it just had a
> POV-Unit diameter and default texture.
I so agree, everything ought to have "sensible defaults" for all but location
(and perhaps size).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> I so agree, everything ought to have "sensible defaults" for all but location
> (and perhaps size).
(?)
Well, considering the troubles people go through, 30 years in, I would say that
a default location at the origin not only makes sense, but is desirable.
[I always pause when I realize that torus {} doesn't take a vector location like
sphere{}, and I have to translate it afterwards, and I still fail to provide a
radius for cylinder when writing one from scratch.]
Rotate and scale, when not at the origin, really mess with people's heads.
(Which reminds me, I ought to write macros like Turn () and Resize () to
translate objects to the origin, perform the inbuilt operation, and translate
back to original location. Macro names are just off the top of my head)
Default sizes ought to be in reference to the unit cell, unless there's some
specific reason to do otherwise. Text {} defaults to 1. Image_map,
height_field, and maybe others default to 1x1, df3 and maybe others default to
the unit cube....
I think that one of the basic themes for 4.0 ought to be consistency.
In size, in uv-mapping vectors, in syntax, and whatever else we can manage.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> @ingo. very happily second that. </grin>
>
Ssst, don't tell, but table definitions are type, except type has grown in more
encompassing direction.
- pascal
type a = record
b: integer;
c: char;
end;
- C
struct a {
int b;
char c;
};
- nim
type
A = object
b: int
c: char
- nim
type
RGB = array[5, float]
Pattern = object
pKind: ....
Texture = object
pattern: seq[Pattern]
Material = object
texture: seq[texture]
template rgb*(r, g, b, filter, transmit: float): RGB =
[x, y, z, filter, transmit]
template `r=`*(colour: var RGB, value: float) = colour[0] = value
template `g=` ...
kind off....
another language that may be of interest is Phix http://phix.x10.mx/ where
everything is array based (https://rosettacode.org/wiki/Category:Phix)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> (Which reminds me, I ought to write macros like Turn () and Resize () to
> translate objects to the origin, perform the inbuilt operation, and translate
> back to original location. Macro names are just off the top of my head)
One (two) more of POV-Ray's internals that I would like to see made available in
SDL, the objects current transformation matrix and it's inverse. But build in
turn, resize would be nice to haves,
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> [...] I have way too many spreadsheets and little pieces
> of paper with scribbles . . .
https://www.zim-wiki.org/index.html a desktop wiki fur such things. I has
options /plugins for version control (even Fossil i.r.r.c)
There are several similar tools like Zim
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
> One (two) more of POV-Ray's internals that I would like to see made available in
> SDL, the objects current transformation matrix and it's inverse. But build in
> turn, resize would be nice to haves,
Ah, and this is why if we could just have a Point *object*, then we could union
that with an object and transform everything at once. Inverse is already
implemented.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
> https://www.zim-wiki.org/index.html a desktop wiki fur such things. I has
> options /plugins for version control (even Fossil i.r.r.c)
Oh, heck yeah!!!
This is exactly the kind of thing I wanted to do - hyperlinked to documents and
files! Potentially with multiple links to the same item.
You are a mind-reader, in a timely fashion.
> There are several similar tools like Zim
Please enlighten me!
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I so agree, everything ought to have "sensible defaults" for all but location
> > (and perhaps size).
>
> (?)
> Well, considering the troubles people go through, 30 years in, I would say that
> a default location at the origin not only makes sense, but is desirable.
> [I always pause when I realize that torus {} doesn't take a vector location like
> sphere{}, and I have to translate it afterwards, and I still fail to provide a
> radius for cylinder when writing one from scratch.]
>
> Rotate and scale, when not at the origin, really mess with people's heads.
yes. the "all but location" was just (habitual ?) personal perspective.
> (Which reminds me, I ought to write macros like Turn () and Resize () to
> translate objects to the origin, perform the inbuilt operation, and translate
> back to original location. Macro names are just off the top of my head)
>
> Default sizes ought to be in reference to the unit cell, unless there's some
> specific reason to do otherwise. Text {} defaults to 1. Image_map,
> height_field, and maybe others default to 1x1, df3 and maybe others default to
> the unit cube....
>
> I think that one of the basic themes for 4.0 ought to be consistency.
> In size, in uv-mapping vectors, in syntax, and whatever else we can manage.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Please enlighten me!
>
https://www.giuspen.net/cherrytree/ https://github.com/giuspen/cherrytree
https://tiddlywiki.com/ Single page web app
https://wikidpad.sourceforge.net/
An alternative way is simple text files in one directory and then a separate
directory structure with a tree of metadata tags. In those you keep the symbolic
links to documents that match the tag.
Going fancy, start your document with the tags. Write software that monitors the
tags dirs and when you copy a simlink to an other tag dir update the tags in the
original document. Same with deletions.I used such a system in the 90' and 00's
to manage my music collection.
....and that is just the beginning, if you keep the news group messages in mbox
you can simlink those too, your file syatem is a database after all .... ;)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Ah, and this is why if we could just have a Point *object*, then we could union
> that with an object and transform everything at once. Inverse is already
> implemented.
Just as an idea,
#declare Thing = object{
local_centre = <1,1,1>
sphere{
<2,2,2>, 1
rotate <20,70, 3> #rotates around the origin
}
sphere{
<0,0,0>, 1
rotate_local <20,70,3> #rotates around the local_centre
}
rotate <33,33,3>
rotate_local <-45,90,22>
}
global and local axis.
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
