POV-Ray : Newsgroups : povray.general : povray standard include files : Re: povray standard include files Server Time
1 Aug 2024 02:18:12 EDT (-0400)
  Re: povray standard include files  
From: nemesis
Date: 16 Nov 2006 06:45:00
Message: <web.455c4e6d341a4ab7f2ff13290@news.povray.org>
Tek:
"I don't mean to sound arrogant, but the only includes I ever use are
transforms, rad_def, and functions, all of which I feel should be part of
the language"

You don't sound arrogant at all:  most of the standard includes are outdated
and are not really useful for most povray users needs.  This is why i began
this topic: to get it up-to-date.  It's kinda of annoying that to get a
truly useful povray library you have to go web crawling in well-known sites
like ignorancia.org, oyonale.org, runevision.com, evilsuperbrain etc.  I
wonder if these "standards" wouldn't find better use as part of the
standard povray include files.

"Anyway my point is, even if we had more include files, I'd never use them!"

That's the do-it-yourself attitude that's so common with highly creative
people:  they enjoy creating new things, from scratch.  But there's another
kind of people too:  the practical folks who want to assemble pre-made
things into a new whole.  I'd call these two kinds of people producers and
consumers.  I'm sure the povray community counts with both types, and they
are not necessarily mutually exclusive.  I'm sure the latter people would
find it rather pleasing to see povray standard includes upgraded.

"The reason I don't use them is, for example, materials inc;ude files only
look right if you have the assumed_gamma used by whoever created the
includes, and no radiosity (because they have an ambient finish)."

how about separate finishes for use with radiosity and similar ones for
no-radiosity settings?  Finishes separate from pigments, separate from
normals as well as interiors, etc.  Encapsulate and assemble them into
macros via parameters.  Have just a few actual predefined textures,
pigments, color_maps etc, by applying the macro.  How about it?  I believe
it's much better than having hundreds of pigments by the suggestive names
of P_WoodGrainPurpleJade7B or something like that...

Perhaps an effort to get povray stdlib more standardized and flexible like
that would help.  Anyone up to the task?

"To make these things work you'd have to make assumptions/standardisations
for lighting (radiosity or not, brightness), scale (since it's a pain to
re-scale each thing, plus media effects don't scale well)... Not to mention
effects that interfere with each other (for example my ocean from p.b.i
doesn't play nicely with fog, because it's hollow so it can be filled with
media)."

I agree.

" I'm just very sceptical that these issues can be resolved in a way
that is simple for newbies to understand and doesn't interfere with more
advanced users."

I see.  It's like the Java language, which severely limits what one can do,
thus not allowing newbies of shooting the own foot, but also infuriating
advanced programmers by verbose and convoluted syntax and semantics.  We'd
have to get a mid-term...

"some better example scenes, which people could tweak to their own ends,
would be better. e.g. have a basic interior with radiosity (e.g. kitchen
scene), photo studio setup, landscape, etc etc."

Perhaps i'm thinking like a programmer rather than an artist, but i don't
believe that would lead to systematic code reuse any more than the ad-hoc
methods we use today.  The poor guys would have to go through the trouble
of messing with the scene -- perhaps even completely breaking it -- and if
he wanted to use any of those objects/textures/settings, he'd have to
manually copy it over to the scene buffer.  Not as simple as a mere include
and macro call at all.

"Sounds like a lot of cataloguing work for someone though."

yes, that's why i'm proposing it to be into povray standard includes.

"Texture competition sounds like a lot of fun, though I'm curious about your
definition of "texture", since my water's an isosurface."

yes, yes.  I'm not thinking about getting just a few more "textures" to the
stdlib, but objects, macros and techniques.  Your sea is excellent, and
since you posted the code to the newsgroups, i wonder how would you feel if
it got into the stdlib, full copyright attached, of course.


Ben Chambers:
"Standardizations would be better than assumptions.
Something along those lines, and then in your objects using

cylinder {<-5,0,0>*inches,<12,0,1>*inches,1*inches}"

yes.  Let's work on something like that, shall we?  How about we get these
discussions into something like the povwiki?

"Lighting might be able to be done in a similar way, with a set of
standard definitions, and all the base colors derived from those.
However, someone who knows more about light would be able to answer this
better than I could."

I would want to see the opinion of Jaime, since his Lightsys is very
complete.

"Of course, in the end it just means you have to build everything for the
library from scratch, but then the library would be extremely reusable."

That's exactly the point:  reusability and standardization.  I don't like
the java language that much, but one thing it truly brought to the table
like nothing before is the efforts in standardization and code reuse, when
compared to the old ad-hoc methods of C/C++.  I know povray source code is
all C/C++ and i'm not suggesting at all a change of language, but a change
of mentality regarding code reuse.  Most open-source C projects these days
have an API which is very OO-like and well organized.  We should make an
effort on standardization and interoperation, perhaps designing a set of
guidelines for include files, naming conventions, values for lighting etc.
From there, we could adapt existing include files to work this way.  And, as
i said before, i'd go for macros rather than predefined stuff.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.