"Mr" <m******r******at_hotmail_dot_fr> wrote:

> Would everyone around here also frown at this?

Kind of ;)  formatting is meditative moment, time for contemplating on the code
at hand. The language server for my editor auto formats on save, it is extremely
annoying as the result is ugly and I have not found how to turn it off.

ingo

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "ingo" <nomail@nomail> wrote:
> > ...
> >   object:
> >     sphere:
> >       center<0, 0, 0>
> >       radius<1>
> >       material:
>
> JSON has been mentioned elsewhere as a replacement (?) or as a component of the
> "new SDL".  it would (I guess) make a real good storage format for objects (like
> above), or materials/textures libraries, etc.
>

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:

CREATE TABLE IF NOT EXISTS sphere(
  //centre: ah, there is no vector type but we could crate a table for that
         id INTEGER PRIMARY KEY NOT NULL,
       name TEXT UNIQUE,
     centre INTEGER REFERENCES vector(id),
     radius REAL DEFAULT 1.0,
   material INTEGER REFERENCES material(id)
)STRICT;

CREATE TABLE IF NOT EXISTS vector(
    id INTEGER PRIMARY KEY NOT NULL, // or use a string formatted as '<x,y,z>'?
     x REAL NOT NULL,
     y REAL NOT NULL,
     z REAL NOT NULL
)STRICT;

etc. etc. who needs type-systems and OOP if you have a database ;)

ingo

Post a reply to this message

"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 ;)

Yes,
Along those lines, I was also trying to look at the similarities of all of the
povObjects to see if we could have some more commonality under-the-hood.  It's
something clipka mentioned.  I have way too many spreadsheets and little pieces
of paper with scribbles . . .

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.

- BW

Post a reply to this message

hi,

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