"clipka" <nomail@nomail> wrote in message 
news:web.49ca88269fb46029c1f399840@news.povray.org...
> If I wasn't working on various other pieces of POV code, that's what I'd
> probably be doing right now...
>
> (Note however that "in the language that pov was written" would mean C 
> until
> only very recently, so nowhere close to dynamic lists whatsoever; and 
> structs,
> although C does have them, would have to be represented internally using
> "arrays of members" as it were, because C can't create new structs at 
> runtime.)

I had a feeling it was C still; long ago I looked at the source when 
considering adding new media scattering methods...then quickly abandoned 
that idea when I discovered how much work would actually be involved with 
the implementation of a new (to pov) algo.. :-|

>> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project
>
> Yargh! Vade! >_<

Hmm? Sounds like something a norseman might shout just after boarding your 
vessel and just before doing something awful with a large blade. ;-)

> Again, too much OO thinking for POV SDL.

OO is the crack of programming. :-)

> You can't store separate things in the multiple dimensions of such an 
> array anyway; and if one of your "subsections"
> would need more elements, you'd need to add more elements to the other
> "subsections" as well... not too bright.

All of the dim1 elements will have the same attributes, so in this case it 
isn't really an issue, as they are just flags really. I do wish I could 
store multiple datatypes though, as using vectors when all you want is a 
flag is somewhat like the programming equivalent of a nasty hacked up 
hairball; ugly, gross and not something you like having to deal with.

> But what you might want to do is:
>
> #declare POINT  = 0;
> #declare COUNT  = 1;
> #declare RANDOM = 2;
>
> #declare Array[i][POINT]  = <...>;
> #declare Array[i][COUNT]  = <0,0,0>;
> #declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;

So using different placed in dim2 would be better than having related vector 
flags grouped in their own dimension?
It seems to me that it could become confusing and require code rewrites (for 
grouping of like flags/misc) if one uses only 2d when thy might have a set 
of flags in d2 for say, branching, child nodes, etc.. and more for 
interpolated vectors or the like. It also seems that using those additional 
attributes could become messy if they are just all over the place.

> (That's basically how struct support would have to be implemented in POV
> internally - except that we'd need to be able to store different things in 
> the
> array elements)

I'd say step one would be to implement vector and integer/double/long 
support in the same array, see what that took to do, and then fan out from 
there.

> or maybe
>
> #macro GET_POINT(a,i)
>  Array[i][0]
> #end
>
> #macro GET_COUNT(a,i)
>  Array[i][1].x
> #end
>
> #macro GET_RANDOM(a,i)
>  Array[i][2].y
> #end

I like that better, seems easier to use and keep track of. I still like the 
idea of using multiple dimensions for related flags for my specific purpose, 
as I won't have many categories. It isn't so much that it really matters, so 
long as whatever method used works and does so quickly. Even so, for general 
extensibility, get/set macros for the win. I'll need to try both using 
stupid amounts of elements, and then compare the stats.

> You can round using "int(x+0.5)", so no problem writing your own macros...

True, but sometimes you just want to use a thing, without having to go find 
math.h to write your own.
There are a lot of little things like that in pov.

> Yes, maybe the standard include files could use an overhaul, too.

Agreed. Especially the textures, a lot of them kinda suck...like the 
metals...and glasses...
I'd like to see a nice influx of textures created by the community. Waters, 
glasses, metals, stones....there are so very many great ones I've seen used 
here.
A lot of the more esoteric macros in povray need example files too.

Maybe once I get my macro suite to a good place, I could get the snowball 
rolling on this..assuming they would actually use any files I created.
Probably if they would, I'd not be alone in wanting to do this.

> .... and a new SDL grammar, as we're on it.

Yes. My vote is cast with using more common C-ish things, as those who 
program will quickly adapt, and those who don't will spend the same amount 
of time learning as before, but will also be familiar with java/c#/c++ ish 
languages without even knowing it. Good for everyone.

>
> For the job we're doing, octrees would come in handy, too.

And hash tables(with a good many hashing methods), and heaps(with a lot of 
heap types), and a proof of the riemann hypothesis, and and and ;-D

> I think one of the greatest current limitations is the inability of arrays 
> to
> store elements of different types. Otherwise, structs could easily be 
> simulated
> by using identifiers holding constants, e.g.
>
> #declare FIELD_FOO = 0
> #declare FIELD_BAR = 1
>
> #declare MyArray[FIELD_FOO] = <0,0,0>;
> #declare MyArray[FIELD_BAR] = pigment { ... };
>
> which still wouldn't be ideal, but still quite an improvement.
>

Indeed. I'd take any improvement at this point.
Any idea why they never did that?

*sigh* I might just have to track down the file(s) where they coded those 
things and have a look...maybe it won't be the massive PITA that I get the 
feeling it is...

ian

Post a reply to this message