"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> 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.. :-|

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... >_<)

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

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

> > 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?

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.

> 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.

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

> > 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...

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

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.

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.

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).

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.

> 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.

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

> > .... 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.

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.

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.

> > 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 don't care about the riemann hypothesis, and I don't think we need dedicated
heaps, but hash tables might be useful at times ;)

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.

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

Yes: C.

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.

Post a reply to this message

"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

>         Guess what? Somebody did a benchmark of an old 1986 Mac against a
> dual core AMD64. And the winner is..... the 1986 Mac! By 9 tests to
> 8 (including a whopping six times faster boot sequence):

  How is that comparing a Macintosh with an AMD64? That's comparing the old
MacOS with Windows.

  It is possible to set up a PC so that it uses coreboot and a architecture-
customized lightweight linux distro. You can get from power-on to the end of
the boot sequence in something like 2 or 3 seconds.

-- 
                                                          - Warp

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Warp wrote:
> "J�r�me M. Berger" <jeb### [at] freefr> wrote:
>>         Guess what? Somebody did a benchmark of an old 1986 Mac against a
>> dual core AMD64. And the winner is..... the 1986 Mac! By 9 tests to
>> 8 (including a whopping six times faster boot sequence):
> 
>   How is that comparing a Macintosh with an AMD64? That's comparing the old
> MacOS with Windows.
> 
	It's comparing a "standard" computer of 1986 and a "standard"
computer of today for "standard" tasks (i.e Word and Excel which is
what most users actually do when they work on their computers).

>   It is possible to set up a PC so that it uses coreboot and a architecture-
> customized lightweight linux distro. You can get from power-on to the end of
> the boot sequence in something like 2 or 3 seconds.
> 
	Of course, and it is also possible to set up this same computer
with an optimized embedded OS that will be even faster and similar
things were already possible back in '86. But then you're comparing
apples and oranges. The point was to compare typical office use of
computers in '86 and today. And the result is that the '86 computer
was at least as fast as today's.

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknLyBQACgkQd0kWM4JG3k9v8QCfSJ5/QDkgXD/XfEa1iCT0um/5
KsgAoIrpcD1AAWOAGchj891v3xwILHa0
=mjzx
-----END PGP SIGNATURE-----

Post a reply to this message

> The point was to compare typical office use of
> computers in '86 and today. And the result is that the '86 computer
> was at least as fast as today's.

  Does "typical office use" include things like opening and editing
a 1600x1200 full color image for a powerpoint presentation?

  I'd like to see you doing that with the old Mac. ;)

-- 
                                                          - Warp

Post a reply to this message