Jim Charter:
"The response I got was:  'It looks like hardened lava'"

Jim, your friend is nuts. :)

seriously, it's a sea of dark blue hardened lava under a blue sky and
reflecting the fading sunset like only hardened lava can!  He's the kind of
guy who goes watch Jurassic Park and goes saying: "Look! another CG
dinosaur!  They can't fool me!" because he knows dinosaurs are not around
to be filmed live and walking robots are still a ways off...

ingo:
"http://objects.povworld.org/"

yes, i send a mail to the site owner about this very discussion but did not
get a reply.

"The POV-Team, and maybe the whole community, is too small to
maintain everything that could be put in."

This is a very good point, but, you see, povray has a very high backwards
compatibility rate.  Even stuff from many years ago can, with just minor
tweaks, run in the latest povray binary.  This is good.  Now, how many
times does the POV-Team has true issues with the stdlib as it is today?
Not really many, i guess.  It's solid code and the SDL backwards
compatibility just ensures this further.  There's not much "bugfixing" in
povray scenes and include files, there's much more additions of new
features and a few fixes to macros.  Textures and objects don't really need
that much attention.  The Utah Teapot is still running just fine. :)

So, my point is that bringing povray standard collection of predefined
objects and textures to more modern times, wouldn't necessarily put more
work onto the shoulders of the maintainers, i believe.

"Would it be useful to create a repository like the above and add to POV-
Ray the option to #include from an URI?
#include "http://incs.povray.org/kitchens.inc""

I don't see how it would help, since the URI can be severely outdated as
well as the files.  It certainly isn't the same as getting a featureful and
more up-to-date standard library...

Summarizing the discussion up to this point, i see people concerned with
copyrights, people suggesting texture contests, URI includes, or the same
old povray objects repository, all of which fall flat of not being included
and integrated to povray.  I see no one actually giving a thought to a more
up-to-date standard include files collection, which was the point of this
post.

Fine by me, but i'll do something about it... i'm thinking something alone
the lines of:  shoot first, ask later.

Post a reply to this message

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 (why's vturbulence part of the SDL but f_granite isn't?!). 
Anyway my point is, even if we had more include files, I'd never use them! 
So I guess that kind of undermines whatever point I'm trying to make with 
the rest of this message... but pressing on anyway:

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). In fact I 
find even though I often use similar settings in my scenes it's extremely 
hard for me to transfer materials or effects from one scene to another 
without some major editting to fit the different lighting setup. Perhaps 
this is a nuance of povray's way of doing radiosity and finishes, but I 
think more likely it's just symptomatic of having such a flexible render 
engine, it's just a lot easier to make scenes vastly different in pov than 
other renderers.

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

Personally I'd say having 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. Each 
with a variety of nicely defined objects and materials that newbies could 
rearrange to their hearts content before needing to understand the more 
technical features of pov.

Anyway just my 2 cents.
-- 
Tek
http://evilsuperbrain.com

"nemesis" <nam### [at] gmailcom> wrote in message 
news:web.4558993a8d8f92ab3976a8750@news.povray.org...
> Sometimes, i wonder why there is this feeling in the povray community that
> everything should be built from scratch.  What i mean is:  while povray is
> an excellent and very versatile software it comes with a very limited
> "standard library" of objects and textures and this sure hampers "code
> reuse".  Specially because this is the 2000's, but the small povray stdlib
> still comes with include files from the 1990's!
>
> I've seen such amazing models, textures and techiniques from many povray
> enthusiasts from over the years.  There are at least two nice lens flare
> include files from well-known POV-Team members, but that aren't featured 
> in
> the stdlib!  What about the many tree and grass macro packages?  Why isn't
> there at least one of them in the standard library?
>
> I wish povray was a lot more used, but i'm thinking it suffers a bit from
> not being "integrated":  if i was a newbie and wanted to quickly create
> stunning scenes, i'd have to crawl the web gathering bits here and there.
> Just imagine:  the other way, the guy wants a kitchen scene and he goes
> like:
>
> #include "kitchen/tiles.inc"
> #include "kitchen/dish.inc"
> #include "kitchen/bottles.inc"
> #include "kitchen/food/fruits.inc"
>
> Or stuff like that.
>
> This is just a rant/wish, but if i could in some way of another to make 
> this
> software more acknowledged, i would.  Heck, i would gladly donate my 
> sample
> scenes and code i post here, without hesitation, crappy as they may be! :P
>
> What do you guys think?  Any chances of something like that happenning 
> just
> in time for Pov-ray 3.7?  If you're fearing the trouble of searching for
> and categorizing all the gathered textures, objects etc, i'd gladly
> contribute to it.
>
> What would it need to get foreign work into povray standard include files?
>
>
>

Post a reply to this message

Of course there's nothing stopping an object collection from collecting 
links to pages where authors have chosen to provide source. e.g. a catalogue 
of nice objects that links to irtc entrant's source zip files that contain 
them!

Sounds like a lot of cataloguing work for someone though.

-- 
Tek
http://evilsuperbrain.com

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:455a16ab@news.povray.org...
> Gilles Tran <gitran_nospam_@wanadoo.fr> wrote:
>> So, no, POV-Ray code is practically never in the public domain.
>
>  I would be extremely surprised if *any* code at all (SDL or anything)
> is in the public domain anywhere.
>  In about 100 years there will start being some, but not before.
>
> -- 
>                                                          - Warp

Post a reply to this message

Texture competition sounds like a lot of fun, though I'm curious about your 
definition of "texture", since my water's an isosurface. Of course, since 
most CSG shapes can be built in isosurfaces, you could apply my water 
"texture" to different objects...

Uh, anyway I'm debating the rules of a competition that doesn't actually 
exist... so just ignore me :)

-- 
Tek
http://evilsuperbrain.com

"Darren New" <dne### [at] sanrrcom> wrote in message 
news:4559f2a0$1@news.povray.org...
> Chris Cason wrote:
>> Well the first issue is that we need to get a written release of 
>> permission,
>> plus if the work is based on another work, that needs permission, etc etc 
>> ...
>
> I was thinking, when I saw the short-code contest announcement, that it 
> would be cool to see a "texture" contest. One submits a texture, be it 
> wood, stone, leaves, water, skin, hair, whatever, in a fairly simple 
> scene, self-contained, not unlike Tek's recent "artistic water".
>
> I'm not sure how good an idea this is, but I thought it would be a cool 
> way to showcase POV, showing off its strengths relative to more 
> model-oriented renderers.
>
> -- 
>   Darren New / San Diego, CA, USA (PST)
>     "That's pretty. Where is it?"
>         "Channelwood."
>     "We should go there on vacation."
>         "..."

Post a reply to this message

Tek wrote:
> 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'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.

Standardizations would be better than assumptions.  I've long thought 
about a standard library of objects based off of common declarations, ie

#declare inch=1;
setup_from_inches()

--or--

#declare meter=1;
setup_from_meters()

Something along those lines, and then in your objects using

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

Or things like that.  Since most of the current objects are not built 
this way, it would mean making everything from scratch.

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.

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.

...Chambers

Post a reply to this message

nemesis wrote:
> Jim Charter:
> "The response I got was:  'It looks like hardened lava'"
> 
> Jim, your friend is nuts. :)
> 
> seriously, it's a sea of dark blue hardened lava under a blue sky and
> reflecting the fading sunset like only hardened lava can!  He's the kind of
> guy who goes watch Jurassic Park and goes saying: "Look! another CG
> dinosaur!  They can't fool me!" because he knows dinosaurs are not around
> to be filmed live and walking robots are still a ways off...
Yes, he was exactly that kind of guy.

Post a reply to this message

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

I was reading all messages in this thread... Uhh! Yes, it is so true and for 
sure a great idea to boost the POV world!

The following targets should be aimed:

1
An item library at the regular POV-Ray website (as sub directory or as sub 
domain), sorted by categories and sub categories. Everyone can add items. 
Each item should be in a measurement common in most countries. I personally 
would vote for the more logical metric system. I would vote against the 
feets system as there the relations are not logical (10 or 100 inch are not 
a foot). And, for easiest usage, the item should be positioned on a standard 
location within the POV-Ray coordinates, let's say, around the total 0.0 
point. Finally, each item should have on top the declarations for all 
textures and colors, and recommendations which other external texture files 
would be recommended. However, the item file should automatically use 
alternative textures if the recommended files cannot be found.  In case it 
is a macro, an explaining text on the possible options (parameters) should 
be there, as well. Finally, an exact measurement in all three axises of that 
item is another important part of that file, too.

2
A texture library at the regular POV-Ray website (as sub directory or as sub 
domain), sorted by categories and sub categories. Each texture needs to be 
dispalyed on a ball, a cube and maybe some other important shapes.

3
Competitions or recommendations or introductions. That happens automatically 
each week with a randomly-selected item/texture, or by votes of users. In 
the last case, a simple voting system should be added to each uploaded 
item/texture which shows a numeric or "star" evaluation system at the 
item/texture.

Greeeeeeeeeeeeetings,

Sven

Post a reply to this message

"Sven Littkowski" <sve### [at] jamaica-focuscom> wrote:
> I was reading all messages in this thread... Uhh! Yes, it is so true and for
> sure a great idea to boost the POV world!

glad to count with your support and enthusiasm, Sven.

> 1
> An item library at the regular POV-Ray website (as sub directory or as sub
> domain), sorted by categories and sub categories. Everyone can add items.

isn't it the same as:

http://objects.povworld.org/

?

Well, except that it would be sponsored and hosted in the povray main site,
for sure.  But there's more:  i'm sure many true gems are hiding in the
vast povray source-code newsgroups.  I believe it should prove to be a
solid starting point.  Taking the time to search through it and sort it out
code that could be reused and properly standardized would takes enourmous
effort for a single individual, but a task-force could do it.  If anyone is
willing to join me in their free-time, we could do this searching by slicing
tasks by time periods in the newsgroupds.

OTOH, many people would rightfully find much easier and more straightforward
-- and more fun indeed -- to simply begin new pov code from scratch rather
than searching old code, fiddling with it to adapt to whatever standards we
come up with and finally trying to get in touch with the original authors to
seek for permission to include in povray.

Anyway, i'd like to know which categories we should begin with so as to
label povray stuff.  My gut feeling is that there are 4 main categories of
users of povray:  1) the math-type who enjoys isosurfaces, fractals and
functions; 2) the artist, who models either in CSG or in polygonal meshes
exported from foreign tools and textures both procedurally and with
bitmaps; 3) the architectural, which just wants to quickly assemble
ready-made stuff and materials to quickly create interiors or buildings; 4)
the animator guy, who deals mostly with meshes and is just using povray as
backrenderer.  I think the pov stdlib should have objects/materials/setups
to satisfy the needs of these people.  Common everyday objects, common
camera and lighting setups pre-made and ready to use and of course, many
materials to get your hands dirty. :)

> I personally
> would vote for the more logical metric system.

me too, but conversion macros would go a long way preventing we drag into
useless unit-measure flamewars.

> Finally, each item should have on top the declarations for all
> textures and colors, and recommendations which other external texture files
> would be recommended. However, the item file should automatically use
> alternative textures if the recommended files cannot be found.
> In case it
> is a macro, an explaining text on the possible options (parameters) should
> be there, as well.

What you're describing is a hack for no proper module semantics and lack of
typing information for parameters.  But it's ok, C and Scheme are two
programming languages featuring such issues, respectively, and yet they do
just fine.  Still in the topic of "alternate textures", i think it'd be
nice if we got a Level-of-Detail parameter to creation macros, like 1 for
basic, 2 for medium, 3 for full so that we could get more detailed
textures/shapes for objects closer.  It could be a global parameter too, i
guess.

> Finally, an exact measurement in all three axises of that
> item is another important part of that file, too.

Previously, i posted this idea:  to have all objects centered at the origin
and with either width or height fitting exactly 1 pov unit.  That way,
scaling and translating it to fit a particular scene would be much easier.
OTOH, with a standardized measure unit in place, there would be no need for
objects to be 1 unit wide, they could get their own correct measures like
you say.

> 2
> A texture library at the regular POV-Ray website (as sub directory or as sub
> domain), sorted by categories and sub categories. Each texture needs to be
> dispalyed on a ball, a cube and maybe some other important shapes.

we could get a script to do just that and automatically generate such setup
scenes.  In fact, i believe povray already comes with such a script.

> 3
> Competitions or recommendations or introductions. That happens automatically
> each week with a randomly-selected item/texture, or by votes of users.

That's nice, indeed.  Many povray users are driven by the excitement of
contests and competitions.  It would be fine if the povray website
sponsered such a contest in order to attract users to contribute to an
ongoing effort to update the stdlib.  I'm sure it would draw interest.  Are
you listening, Chris? :)

Post a reply to this message

in news:web.455ba432341a4ab72e704a1e0@news.povray.org nemesis wrote:

>   Now, how many
> times does the POV-Team has true issues with the stdlib as it is today?

Ah, I didn't mean it as that there would be a lot of bugs to fix but I 
thought about the amount of work that goes into updating all include files 
between releases to keep the compatibility. I remember it was quite an 
effort going from 3.1 to 3.5.

Ingo

Post a reply to this message