"clipka" <nomail@nomail> wrote in message 
news:web.49cab78d9fb46029c1f399840@news.povray.org...
>
> There are still some areas where the code is quite C-ish, and a few C-ish 
> data
> types are still waiting to be "classified", but the coding style has 
> changed
> quite dramatically. It now resembles software, not a hack ;P
>
> (Speaking of it - ever seen the NetHack source code? *That* is something 
> to
> drive every OO-enthusiast mad... >_<)

I'll have to check NetHack out. Yup last time I looked at the POV source I 
think it was looking back; kinda like when you leave something in the fridge 
too long and it grows a 'fro, and you aren't so sure who is about to throw 
who away. ;-p

> Well, I was thinking more of the latin "Vade Satanis!" :P

Gotcha! ;-D
Yeah some code looks more like Inno A Satana than much else. ;-p

>
> Yeah, because it doesn't waste so much space. See, your approach used 
> N*2*2
> array entries - so far! This one only uses N*3 entries. Saves you N 
> entries in
> this case. Depending on how many groups you have, and how much they differ 
> in
> size, this can quickly get a lot more. E.g., if one group only had a 
> single
> entry while another had 8, you'd waste N*7 entries.

They would all have the same number of entries; but you do make a valid 
point. The way I was doing it isn't very efficient.

> You cannot avoid *some* kind of mess with POV's SDL.

:-(

> Most of them date back to the pre-Radiosity era; that's why they have 
> ambient in
> them, and that's why they do suck indeed.

I think the metals include file will be my first project. I have some of my 
own that I'll start out with, as well as improving the old ones. I think 
I'll put a section on my website for this, showing previews (rad/norad) and 
code. I may create some facility to allow users to upload code, or I may 
just do a call to arms in the newsgroup. I have a VAST archive of povray 
files, and some have some killer metals in them. I guess I'll need to track 
people down and get permission for things..


> I guess the POV team would agree. The major problem is that although the 
> POV
> community is obviously alive and kicking, nobody seems to see that here's 
> where
> they could help the dev team quite a lot.

Almost nobody. ;-)

> People possibly don't get involved because they think developing POV 3.7 
> is all
> about C++ programming. Well, it is not: POV 3.7 will need various updates 
> to
> the documentation. POV 3.7 would greatly benefit from a major overhaul of 
> the
> include files. And so on. Someone just needs to take the lead, team up 
> with
> others here to get those things done, and in the end lay the results in 
> front
> of the dev team to get it all approved. All the while the dev team can
> concentrate on C++ coding.

Yup, there are spelling errors that I have seen in the docs. I think my main 
focus will be textures and later demo files for esoteric 
functions/macros.I'll probably include a standard set of macros that people 
seem to use a lot, but aren't included. Perhaps I'll write an insert menu 
addon for them.

My concern is future changes in 3.7; it would be a shame to get this all 
polished and then have it break in RC1 or some such.

> I took the step from a normal POV user to a code contributor because I 
> wanted
> both symmetric multiprocessing *and* radiosity, which wasn't available end 
> of
> last year.
>
> If you want better textures, why not take a step forward, too, and become 
> a
> contributor of texture include files? You don't even need to do all on 
> your
> own. Beg, steal or borrow whatever you think should be part of a "POV 
> starter
> pack". Or hack up some macros you think every POV user should have at 
> their
> disposal - you seem to be darn good at it, except for some lack of 
> experience
> (but really making up for it by a strong will to experiment, and actually
> benefiting from that lack by looking at things from a different and fresh
> perspective).

While I doubt stealing would be appreciated by the community, I can always 
make my own versions of anything that I can't get permission for. ;-D

I think that I will host some of this stuff on my site, so that people can 
view and give feedback/improve/debug. Setting that up will take a bit, I 
will probably not have usernames/logins just yet, but if I choose to allow 
others to upload content, I'm sure as hell going to screen applicants. I 
don't need any security issues...or jagoffs uploading pr0n...

> You know, becoming a contributor to the POV package is not difficult: Just 
> pick
> a thing you *want* improved and think you *could* improve if given the 
> chance -
> then step forward here in the newsgroups, making clear that you would like 
> to
> have a go at it, and I'm quite sure you will *get* that chance.

Sounds like a capital idea, and a reasonable task which can be completed in 
a reasonable time given the scope I wish to attack.

> Do so. And expect them to do appreciate your contributions.

I've been using this program for more years than I'd like to admit to, given 
my current skill level...but it's time for me to give something back. ;-D

> Yeah, that would (roughly) be the direction I'd suggest, too. I guess 
> there's no
> "syntax family" as big as the "C-alikes", ranging from C over C++, Java, 
> C# to
> JavaScript (so web designers should be familiar with it as well) or even 
> some
> unix shells.

Exactly, I can't see any possible disadvantage to this as of yet.

>
> However, for some statements I would take a radically different approach. 
> For
> instance, although I'm perfectly accustomed to it, I never got to really 
> like
> the C-style 'for' loops. For my taste, "for" loops should always iterate
> linearly (99% of all C 'for' loops do anyway); and there should be a 
> "foreach"
> loop to iterate over data containers.

I do like my foreach. Actually, I like all the loop types available. There 
is always that one time when you need the weird one.

> I don't care about the riemann hypothesis, and I don't think we need 
> dedicated
> heaps, but hash tables might be useful at times ;)

hehe...yeah all pov needs after all that is a windowing framework and we can 
start cranking out apps in SDL. ;-p

> But I really wasn't kidding: As we're dealing with objects in 3D space, I 
> think
> really the most "natural" data structures for a lot of problems would 
> indeed be
> spatial subdivision trees, and octrees would probably the most widely 
> applicable
> of those.

I think you are right, as many of the other types are only good in very 
specific circumstances, and can be weird to implement.

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

D'oh!

> You don't think about such stuff as long as you're coding straightforward
> classic C. In that language, you don't mix data types. Real C programmers 
> just
> don't think OO. It's almost a break of style that there is a generic 
> object{}
> statement.
>
> Fortunately, the dev team doesn't have any real C programmers among their 
> ranks
> anymore (as far as I know); the internals are getting migrated to C++; and 
> it's
> probably about time for the SDL to head for OO, too.
>

*does a little dance*
w00t! :-D

ian

Post a reply to this message