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

nemesis wrote:

> 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 been tempted to open POV-Mart, a web page made to look like a 
catalog of stuff, with .INC files for everything.

Maybe when I'm not on dial-up...

Regards,
John

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> 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?

Yeah, I've thought the same thing. Would the people who provide all the code
examples mind if some were put into the standard include files? I know that
there's a tradition of doing one's own work, and I myself have reinvented
the wheel several times (mostly poorly :)), but it would be nice if some of
those textures and objects came with POV-Ray.

Are there good reasons for not doing this? Perhaps the licensing would be
difficult...

I would of course be happy to contribute my own objects and textures, such
as they are.

Maybe the revival of the POV-Ray objects collection would do the trick.

-Stefan Sittler

Post a reply to this message

nemesis wrote:
> What would it need to get foreign work into povray standard include files?

I think one problem hampering this is integration within POV's menu 
system.  Currently, most people have far more potential in the include 
files they already have, then they realize.  Sure, you COULD browse the 
docs (as it lists most (or all?) of the includes), or browse the source 
code itself, but most people never do.

I'd recommend starting by making an improved Include menu (I know 
there's at least one project out there that does so, but I don't 
remember who made it) which features EVERYTHING from the Standard 
Include files.

The next step, would be to find what you believe are the most common / 
useful include files that aren't bundled with POV-Ray, and work them 
into your Include menu (with the authors' permission, of course).

Once that's done, petition the POV-Team to replace the standard Include 
menu with your own custom one.

...Chambers

PS You DID ask what it would take to get done :)

Post a reply to this message

Ben Chambers wrote:
> I'd recommend starting by making an improved Include menu (I know 

Bah, it's the Insert menu.

> there's at least one project out there that does so, but I don't 

OK, the best insert menu addon I know of is at 
http://www.f-lohmueller.de/pov_tut/down/insert_a.htm



And I know that the current Insert menu lists the current include files, 
but that's not enough IMO.  Each one should be a separate sub-menu, with 
an entry for each and every material / texture / finish / shape / 
kitchen sink.

Then, we'd see more people using what we already have.

...Chambers

Post a reply to this message

nemesis wrote:
> What would it need to get foreign work into povray standard include files?

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 don't deny the standard scenes and includes could be supplemented usefully,
perhaps as an additional download (or included with the standard one - I
think people are a bit less worried about download sizes now than they were
ten years ago).

In terms of an object collection, while it's something I'd love to see, to do
it properly would probably require that we have some sort of standard means
to 'encapsulate' an object. By that I mean that if you want to for example
'#include "kitchensink.inc" in your scene, it would help if the way you /use/
the kitchen sink is standardized, with respect to the initial size, placement
and so forth. Another possibility is to have some standard 'knobs' that all
such objects share (where 'knobs' are a set of predefined SDL variables that
can be set prior to the #include, or passed in the macro call if applicable).

I have some other ideas for objects, too, but that's not for now.

If the community wanted to work together to come up with a system that would
smoothly integrate with other people's workflow by providing some standards
such as this I'd be quite prepared to support it by setting up a site for it
and providing whatever hosting support is needed.

-- Chris
   POV-Team

Post a reply to this message

Ben Chambers:
"I think one problem hampering this is integration within POV's menu
system."

While i'm probably in the minority here, i don't use povray menu system at
all:  i use Linux at home and open the pov file i'm working on and a few
include files in vim.  It gives me nice syntax highlight and identifier
completion.  Other than that, i know a large deal of the language and what
i do not know or have doubts, i lookup the manual.

Sometimes, i do some poving at work -- my workplace luckily doesn't feature
the "No pov" sign as featured in some JVP's images :) -- running Windows,
but i still don't use it to or else i may forget the language and
constructs. yeah, call me a gluton for punishment... :P

Anyway, my point is that while integrated Insert Menu would be good, it
doesn't hamper not including more and more up-to-date include files.

Chris Cason:
"t would help if the way you /use/
the kitchen sink is standardized, with respect to the initial size,
placement
and so forth."

Yes, indeed.  Very good point.  I myself use the following convention:
model an object freely and when i think it's good enough to be in the
libray, i use a "metric checkered plane" in the background and orthographic
camera placed -5*z.  Then, i resize the object so that either height or
width fits 1 unit wide and then try to place that exactly at the center
(for symetric objects) or placed upon the origin (for chairs, for
instance).  Following that, it's easy to place it anywhere in scenes or
rotate and scale according to current needs.

"If the community wanted to work together to come up with a system that
would
smoothly integrate with other people's workflow by providing some standards
such as this I'd be quite prepared to support it by setting up a site for it
and providing whatever hosting support is needed."

Listen to Chris, people!

I've seen such efforts in the past, like the old Povray Objects Collection,
but this is an effort to actually get some of those INTO povray standard
libs.  I'm more than eager to do that.  Anyone with me?

Post a reply to this message

"nemesis" <nam### [at] gmailcom> schreef in bericht 
news:web.4559c29c341a4ab7f2ff13290@news.povray.org...
> Listen to Chris, people!
>
> I've seen such efforts in the past, like the old Povray Objects 
> Collection,
> but this is an effort to actually get some of those INTO povray standard
> libs.  I'm more than eager to do that.  Anyone with me?
>

I certainly would support such an action!!

As Ben Chambers has mentioned, there is 
http://www.f-lohmueller.de/pov_tut/down/insert_a.htm which is a very nice 
addition to the insert menu; there is the isoCSG menu by Cristoph Hormann 
(http://www.imagico.de/pov/tools.html); both should be standard in POV-Ray, 
I believe. They reside in my Insert menu, and while I do not use them dayly, 
they come in very handy as soon as I need something specific.

Concerning objects, I think those would need a special menu, perhaps 
separate even from the Insert menu? Alternatively, a revival of the POV-Ray 
Object Collection is perhaps indicated. In any case, some standard rules 
should be defined in order to be allowed to upload, like using the POV unit 
as the norm (with automatic scaling to metric or imperial systems?) etc, 
etc...

Finally, I agree with Nemesis that we shouldn't always (have to) re-invent 
the wheel. Creating from scratch is certainly very useful for learning (I do 
it often), but it can be in the way to a creative process. In that latter 
case, being able to pull things out of the box, as it were, works much 
better and is much more productive.

Thomas

Post a reply to this message

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

"Smws" <smw### [at] poboxcom> wrote:
> Are there good reasons for not doing this? Perhaps the licensing would be
> difficult...

I'm guessing most povray code published to websites like
povray.text.scene-files, Povray Objects Collection or even the IRTC are in
the public domain.  They were published without a copyright attached and in
some of them it's even impossible to determine any way to contact the
original author (no email or out-of-date).  Besides, people posting to
these places seem to actually WANT to contribute to povray in a certain
sense or else they wouldn't publish it.  I may be wrong...

> Maybe the revival of the POV-Ray objects collection would do the trick.

It would still fall in the same problem:  someone has to search over the web
to have a nice library.  I'm thinking more of bringing the povray standard
include files a facelift for more modern times.  I'm not thinking about
replacing the old files, but to complement them with more modern and
featureful addons.  If you want basic textures for objects far away, stick
with the classics, if you want very detailed layered texture_mapped
textures, you have it in the very own povray stdlib as well.

I want a more modern standard complex object other than the bicubic_patch
Utah Teapot that comes with povray as well.  Blender has a monkey head! :D
Chairs, bottles, vases, dishes, a few furniture all come to mind as well.

It should be cool to cram into povray stdlib all the nice techniques the
povray community has come up with all over these years. :)

Post a reply to this message

"nemesis" <nam### [at] gmailcom> a écrit dans le message de news: 
web.4559f466341a4ab73976a8750@news.povray.org...
> I'm guessing most povray code published to websites like
> povray.text.scene-files, Povray Objects Collection or even the IRTC are in
> the public domain.  They were published without a copyright attached and 
> in
> some of them it's even impossible to determine any way to contact the
> original author (no email or out-of-date).  Besides, people posting to
> these places seem to actually WANT to contribute to povray in a certain
> sense or else they wouldn't publish it.  I may be wrong...

It's a complicated topic, but in a nutshell copyright is automatic, except 
for certain works, like official publications in certain countries, that are 
directly in the public domain. Copyright expires after a certain period of 
time, but POV-Ray isn't old enough for scene files to enter automatically in 
the public domain... Actually, for an individual, releasing something in the 
public domain is not straightforward either: one can always put a disclaimer 
and wave his/her rights (this is what I did for the scene/image I uploaded 
for the Wikipedia article on POV-Ray), but this does not mean that the 
disclaimer will be legal everywhere.

So, no, POV-Ray code is practically never in the public domain. However, as 
people have been more aware of these issues lately, recent code often has a 
clear license attached (one from Creative Commons for instance).

G.

Post a reply to this message

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

Darren New wrote:
> 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.

I think it's an excellent idea. I don't think I've ever seen a texture
contest. (I'd include 'materials' in that category too). Though I have no
idea how you would judge such a contest unless you set specific goals.

-- Chris

Post a reply to this message

Chris Cason wrote:
> idea how you would judge such a contest unless you set specific goals.

When I travel, I often take photographs of textures, just to use in 
other artistic-type projects. Perhaps verisimilitude to actual 
photographs? Or simply "here's five judges, and we let them pick"?

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

Darren New wrote:
> Chris Cason wrote:
>> idea how you would judge such a contest unless you set specific goals.
> 
> When I travel, I often take photographs of textures, just to use in 
> other artistic-type projects. Perhaps verisimilitude to actual 
> photographs? Or simply "here's five judges, and we let them pick"?
> 

Or maybe just, "Every texture we think is worth including, we'll 
include"? :)

...Chambers

Post a reply to this message

nemesis wrote:

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

Actually, some of my Thoroughly Useful Macros were slightly renamed and 
put into one of the standard includes, so there are some additions over 
time.

However, standard objects, such as dishes, tables, and so forth tend to 
be easily recognizable as copied items.  To have the variety that many 
POV artists would demand would require a very large library of stuff, 
which takes time to debug, etc.

Regards,
John

Post a reply to this message

Darren New:
"I was thinking, when I saw the short-code contest announcement, that it
would be cool to see a 'texture' contest... I thought it would be a cool
way to showcase POV, showing off its strengths relative to more
model-oriented renderers."

I for one welcome our new texture masters overlords. :)

A very good idea, indeed.  But what is preventing you from showcasing
textures in the short code contest right now anyway? :)

Gilles Tran:
"Actually, for an individual, releasing something in the
public domain is not straightforward either: one can always put a disclaimer
and wave his/her rights.  So, no, POV-Ray code is practically never in the
public domain."

It's a complicated matter indeed.  What happens if some random guy named
under an alias -- say, nemesis -- posts a scene file to one of those web
povray collections, without email or anything?  Isn't it in the public
domain?  Anyone can claim ownership to it.  Isn't that the meaning of being
in the public domain?

"However, as people have been more aware of these issues lately, recent code
often has a clear license attached (one from Creative Commons for
instance)."

Yes, and I know IRTC entries licenses read "COPYRIGHT: I SUBMIT TO THE
STANDARD RAYTRACING COMPETITION COPYRIGHT." so they are covered.  But who
has the copyright to that?  In the case of well known personas as you,
Jaime, Jim Charter or others, it isn't a problem at all.  It is a problem,
though, for files submited by users under strange nicknames, with no
working email or any contact reference whatsoever.  The IRTC even mantains
a FAQ to that.  The IRTC doesn't own the copyright even to those works
whose authors are virtually unknown.  What prevents one -- say, me -- of
going there and claiming the copyrights over one of those works?  Could i
then demand them to remove the image from their servers?  If that's so, if
anyone can do that, i believe it's in the public domain.

Warp:
"I would be extremely surprised if *any* code at all (SDL or anything)
is in the public domain anywhere."

If someone can explicitely grant another rights to modify software, can't
someone explicitely say "I hereupon put this software into the public
domain"?  I believe i've already seen genuinely public domain software with
such legalese in the DOS freeware days...

Anyway, my intention wasn't to ignite some copyright controversy.  I myself
post source code in these newsgroups, under this very nickname.  Of course,
most of the time they are very crude scenes explicitely showcasing one
technique or another i thought to be useful in the large, but nothing
compared to the works of art from povray masters like Gilles and others.
So, i don't know if i'd be so eager to share code of something i'd think to
be a crown gem. ;)

However, it's not like authors from chosen works would give up copyrights to
get into povray stdlib.  My point regarding "public domain" work was aimed
exclusively at code hanging around in the povray newsgroups or old IRTC
scenes whose authors can't be contacted anymore or those ad-hoc web
collections of povray code, whose original authors, again, can't be
contacted:  these people explicitely released povray code in the wild for
the very reason to share them with people, except in the case of IRTC
entries.

I wasn't thinking of Jaime's or Gilles' or others works because, not only
they are clearly copyrighted and with very visible authors, but also
because in the eventuality of getting something like Gilles' maketree macro
or Jaime's Lightsys into povray stdlib, it could put some pressure onto
POV-Team members regarding mantainence of said code.  Would it be fair to
let people complain at the POV-Team about the state of code from other
people but which happens to be distributed together with povray?  In the
eventuality of such 3rd party code going into povray's distribution as part
of the stdlib, would the original authors explicitely grant the POV-Team
members any copyrights so that they could modify them if for no other
reason than to bug fix them?  these are good questions i'd like you to
think...

OTOH, said code is pretty stable by now and if we got around with current
stdlib being almost entirely 10 years old with few updates or "bug fixes"
throughout, i think we could get around with these as well. :)

John VanSickle:
"some of my Thoroughly Useful Macros were slightly renamed and put into one
of the standard includes"

good to know and i knew i've seen your name before...

"standard objects, such as dishes, tables, and so forth tend to
be easily recognizable as copied items.  To have the variety that many
POV artists would demand would require a very large library of stuff,
which takes time to debug"

yes, yes, another very good point.  I'm actually more wishful of actually
putting current povray to good use by, rather than just having a few
predefined textures and objects, having some macros to parametrize such
ojects and textures in someway, by adding some randomness to them and
different color_maps and patterns applied.  Then, you have the original
objects/textures predefined from the generated macro by adding 0 randomness
and the original parameters. :)

Ben Chambers:
"Or maybe just, 'Every texture we think is worth including, we'll
include'?"

Yes, i know where this is getting at:  what to include into an updated
povray stdlib?  Are people voting?  More is better?  Who am i to say?  I
opened this topic to get people from the community thinking about it.  I
think it's up to us as users to work up with POV-Team members the what, how
and when of povray present and future.  It's not like we're demanding
features:  we're willing to help make povray a more enjoyable software.

Povray stdlib is like C's, with just a few crude, basic, lowlevel
functionality available.  What i'm proposing is expanding it into something
akin to Unix's libc or something more.  Not quite gigantic as Perl's CPAN or
Java's stdlib and multiple frameworks, but a lot more useful than as it is
now.  Or we can just leave it as it is and go on with our own ad-hoc,
built-from-scratch work methods as before. :P

Personally, i think it would be awesome to get to quickly create a file such
as this:

#include "transforms.inc"
#include "utils/units.inc"
#include "setups/basic_stage.inc"
#include "places/interiors/kitchen/teapot/utah/shape.inc"
#include "places/interiors/kitchen/table/jvp.inc"
#include "places/interior/kitchen/food/biscuits/pov.inc"
#include "textures/metals.inc"

#local teapot = object { teapot scale x*22*cm texture { glossy_metal } }
#local table = object { table_2004 scale y*1.4*m }

place_upon( teapot, table ) // places it upon the table, at the center
// move it somewhat away from the center
#declare teapot = object { teapot translate -z*30*cm rotate -y*40 }

set_stage( teapot ) // sets a simple stage scene for the object
// set_stage already sets a default camera.  adjusting it a bit
camera { stage_cam rotate 30*x }

This scene should show a basic stage (spotlighted) scene depicting a Utah
teapot in glossy_metal texture upon Jaime's table from his 2004 kitchen
scene (cloth and all).  This is just my imagination going wild... :P

Some would call this simple "ripping" from well stabilished classics.  I
call that nice code reuse. :)

Two things to note:  1) i've gone for a deep hierarchical approach to
library organization in which objects are conceptually connected,
specifically, locally connected as in the real world.  You're likely to
find food and dishes in a kitchen, right?  This is similar to how
object-oriented frameworks are organized as well.

2) There should be many kinds of tables in a kitchen, jvp's is just one of
them!  same for teapots. :)

Well, (2) raises the question:  how to solve inevitable "namespace"
conflicts for similarly named identifiers, like, say "kitchen/table" and
"restroom/table"?  This is something to give some serious thought.  I won't
try it now, because i'm very sleepy and a mess would come out from it... :P
some help here would be nice!

By the way, i think the alias i got for this newsgroups make people a little
suspicious of me -- like i'm trying some IP theft or something -- so let me
properly introduce myself:  i'm Ricardo Malafaia from Brazil, 32 years old,
software programmer.  not just another anonymous web persona anymore. :)

Povray to me is a hobby i've finally got some time to catch on.  I also use
it as a relief from the stress of daily annoying commercial software
development with stupid commercial tools and languages.  Povray is very
good as that too. :)

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> A very good idea, indeed.  But what is preventing you from showcasing
> textures in the short code contest right now anyway? :)

  The size limitation.

> If someone can explicitely grant another rights to modify software, can't
> someone explicitely say "I hereupon put this software into the public
> domain"?

  The problem is that copyright legislature of most countries don't have
a notion of "putting something in the public domain". In fact, most such
legislatures, quite ironically, don't even have a concept of "public domain"
explicitly (they just have the notion of copyright expiration).

  This means that someone can state "this is public domain", but that
doesn't necessarily have any legal relevance. Many lawyers strongly
suggest not relying on such a statement, but instead they recommend
using an explicit license such as the MIT license or Creative Commons.
Those licenses have legal authority, while "publid domain" might not.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> 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.
> 
The caveate, I think, is that textures are not so autonomous.  There 
success depends significantly on context, expecially lighting, but also 
the objects, their scale etc.  Sometimes a texture effect requires 
finish parameters that are quite extreme and work in conjunction with 
the whole scene

Example:
Back in the day I once showed this picture
http://oz.irtc.org/ftp/pub/stills/1998-10-31/danocean.jpg
to someone I worked with to demonstrate the power of POV-Ray.  The 
response I got was:  "It looks like hardened lava"  Well yeah, I does 
look like hardened lava but it also looks like a photo of water under a 
plausible set of circunstances like low light, from a moving ship, and a 
slow shutter speed, etc.  The picture reminded me much of WWII naval 
photographs in fact.   So I thought it was very good and real, but I was 
also applying a somewhat forgiving "eye" to the result.

I believe this is also the reason why the attempt to collect texture 
examples at povwiki met with only limited success.  It is very difficult 
to buuild a texture that will work universally whatever the context it 
is put into.

So such a contest would be interesting, but I think this dependency 
issue would need to be addressed or else I could see the thing leading 
to frustration.

Post a reply to this message

in news:web.4558993a8d8f92ab3976a8750@news.povray.org nemesis wrote:

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

Just some notes,

http://objects.povworld.org/ This project started quite some time ago, 
but somehow never got real momentum. Few objects where submitted. Then 
the collection wasn't managed for some time, etc...

Maintenance of includes can be(come) problematic over time. For example 
my own Meshmacros, I haven't looked at them for at least two years, it's 
sad. Same for some of the statistics stuff and sunpos in the standard 
library. In the end, the team has to maintain it. No guarantee that I or 
any of the other contributors will be around when the next release 
comes. The POV-Team, and maybe the whole community, is too small to 
maintain everything that could be put in.

Would a sourceforge like system be useful as an addition to a site that 
collects inc's? I've been thinking about putting some of my includes up 
there, or at google's equivalent, but I'd prefer to have them on the 
povray.org

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"
And then somehow make sure that you include the right version of it ;)


Ingo

Post a reply to this message

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

ingo <ing### [at] tagpovrayorg> wrote:
> I remember it was quite an
> effort going from 3.1 to 3.5.

hmm, such an effort every, what?, 6 years doesn't sound bad to me. ;)

but really, if we go the macro way and have a few actually predefined
materials from the macro calls, it should prove even easier to maintain
later...

c'mon let's make one hell of a 3.7 povray release! :0  or at least, prepare
the way for povray 4.0 some years from now...

Post a reply to this message

"Ben Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:455bd0f5$1@news.povray.org...
> 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.

Reuseable by anyone who's happy to make scenes obeying those 
standardisations. If someone tries to standardise my lighting I'll punch 
them! :-D

-- 
Tek
http://evilsuperbrain.com

Post a reply to this message

"Tek" <tek### [at] evilsuperbraincom> wrote:
> If someone tries to standardise my lighting I'll punch
> them! :-D

ah!  the romantic artist viewpoint!  what would be of Monet with standard
lighting compliance?... :P

still, it should be there for people who want it and those who want accuracy
rather than poetic license...

we could include an on/off switch, of course... :)

Post a reply to this message

I'm not sure --- I would rather have a set of standards written OUTSIDE of
pov, an ISO/ANSI/POV-SO? of sorts, that can be conformed to by direct
choice. It would be fantastic to have a format to follow with a scene file,
a way to think about lighting, and all that jazz. But I don't want it
written into pov. User-friendlyness is just another word for
'thinks-it-knows-what-I-want-better-than-I-do.'
 Similar with the object includes. If it is sitting right there, all we end
up with are the thousands of 'big green apple in a little room, with a
paintbrush and a artists' wooden model' scenes, like the big fancy
commercial programs did for so long. Who the heck wants to see another
perfect, mass-produced virtual teapot?

No, as an artistic community we cannot make this choice for technical ease.
I would love to see the return of the object library, don't get me wrong.
And standards for the creation and manipulation of objects, etc? I'd use
them. I'd be all over them. But give me a terrible-looking sink that took
me 2 hours to make over an object{sink} any day. Given less primitive
objects, all we are doing is accepting less control; and control is one of
POV's most competitive features. Besides, if you hard-wire any of this in,
you imply that it ain't gonna change 'till the next installment of POV ---
and that could be quite a while.

I don't know. I'm an idealist (does it show?), but for whatever reason, I
just react to this viscerally. Yeah, I know I don't have to use whatever
you put in. Will that choice even occur to new users, though? Nah. Heck,
who reads the docs *now*, let alone---
Ugh. I keep trying to wrap this up. I just worry about how long it would
take before I wore down hand-crafting scenes and used the telephone, and
then the keys, the light, the floor and the wall and the ceiling from the
includes... I'm not intellectually against using a few accessories to get a
scene done and looking good. But where will it end?

Wow! I've always wanted to say that! heehehehee.

Signing off.

--
Sam Bleckley
stm 31415 (at) g mail . co m

Post a reply to this message

stm31415 wrote:
> I'm not sure --- I would rather have a set of standards written OUTSIDE of
> pov, an ISO/ANSI/POV-SO? of sorts, that can be conformed to by direct
> choice. It would be fantastic to have a format to follow with a scene file,
> a way to think about lighting, and all that jazz. But I don't want it
> written into pov.

Noone's talking about writing anything into POV.  We're talking about 
include files that come with POV.  The SDL would still exist in its 
current form.


> User-friendlyness is just another word for
> 'thinks-it-knows-what-I-want-better-than-I-do.'

Sometimes yes, but overall user friendliness is an important aspect of 
design.

>  Similar with the object includes. If it is sitting right there, all we end
> up with are the thousands of 'big green apple in a little room, with a
> paintbrush and a artists' wooden model' scenes, like the big fancy
> commercial programs did for so long. Who the heck wants to see another
> perfect, mass-produced virtual teapot?

Noone.  However, I've love to see a big green apple inside someone's 
eye, or some other artistic usage of the objects.  Having the objects 
available just means there is one less barrier between the artist and 
his final render.

> No, as an artistic community we cannot make this choice for technical ease.

Why not?  Many artists are more concerned with artistic composition than 
technical creation anyway.

> me 2 hours to make over an object{sink} any day. Given less primitive
> objects, all we are doing is accepting less control; and control is one of
> POV's most competitive features.

You wouldn't have less primitive objects.  You'd have all the primitives 
you have now.  You would also have a large library of predefined 
objects, textures, finishes, media, etc to choose from.

> Ugh. I keep trying to wrap this up. I just worry about how long it would
> take before I wore down hand-crafting scenes and used the telephone, and
> then the keys, the light, the floor and the wall and the ceiling from the
> includes... I'm not intellectually against using a few accessories to get a
> scene done and looking good. But where will it end?

What's wrong with that?

Around a year ago I was woring on a scene for p.b.i. of a dandelion 
growing in a glass jar, on a windowsill.  Most of the work I did, was 
for the wall and a bottle.  I spent days working on them (status update: 
I lost the code :(, so if I ever return to it I'll have to start from 
scratch), when with a good object library I'd have been done in 5 
minutes.  Then, I could have spent the time on better things.

I would love for this project to get off the ground, and I would 
definitely use the objects it provided.  Of course, there is a certain 
standard of quality: the key factor is that everything provided must be 
*worth* using, meaning we need not only high quality textures, but high 
quality CSG objects.

Anyway, enough ranting for now.

...Chambers

Post a reply to this message

"stm31415" <sam### [at] cscom> wrote in message 
news:web.455f2829341a4ab7cf1900cc0@news.povray.org...
> I'm not sure --- I would rather have a set of standards written OUTSIDE of
> pov, an ISO/ANSI/POV-SO? of sorts, that can be conformed to by direct
> choice. It would be fantastic to have a format to follow with a scene 
> file,
> a way to think about lighting, and all that jazz. But I don't want it
> written into pov. User-friendlyness is just another word for
> 'thinks-it-knows-what-I-want-better-than-I-do.'

I agree with that idea, users should have to choose to enter into this 
standard, it shouldn't affect anyone else.

But I would point out one problem: If you have a set of include files to 
make building scenes easier by standardising things, then you'll never be 
able to use any of my code, or the code of any other pov artist who doesn't 
work within those standards. In fact if we assume we're talking of a library 
of include files to make things simpler, then it stands to reason that most 
people who use it won't be particularly skilled, and as such the library is 
going to be a pain to extend with any high quality elements. You'd need some 
skilled povvers to dedicate a bit of time to build new models or port nice 
models into that standard...

Anyway I'm just waffling. It sounds like a lot of work and I take my hat off 
to anyone with enough community spirit to do it! :)

-- 
Tek
http://evilsuperbrain.com

Post a reply to this message

Standards: For some of the big ones, I see scaling, rotation and translation
as a fact of life when you're placing objects in SDL.  If you use other
peoples' #includes, I'd say expect to let people make their objects in
whatever measurement system and coordinate handedness they want.  But from
the opposite standpoint, when you go to make #includes that other people
might use just make sure it's documented and flexible/easy to use:

1. Document what coordinate and measurement systems it's in, and where the
origin is in relation to it.

2. Add commented-out lines to convert handedness (etc) if you're feeling
nice.

3. If your #include uses macros to create objects, make sure they're
flexible enough to handle different situations.  E.g. it would be better
for the macro to define an object/union to be placed by the user, giving
them a chance to modify/convert scale etc, than for the macro to also place
the object(s). Otherwise, the macro should be sufficiently parameterized.

4. Include a sample scene (like most do)! or... one thing I like to do is
make #inc's self-renderable.*


Charles


PS
*(Defines variable Main_POV_File if it does not already exists at the
beginning of the file, and then uses strcmp() on this variable at the end
of the file to determine if it should use a sample scene & camera.  I.e., a
convienient way to get a preview which can be easily defeated by somebody
not wanting to use this system.)

E.g. my "manager desk.inc" starts with this line:
#ifndef(Main_POV_File) #declare Main_POV_File = "manager desk.inc"
#ifdef(Red) #declare Main_POV_File="nRed already definedn"#end
#ifdef(camera) #declare Main_POV_File="nCamera already definedn"#end
#debug Main_POV_File #end


PPS, it'd be really cool if POV-Ray had a built in string constant named
main_pov_file or main_scene_file or primary_sdl_file or something like that
based on whatever file is the first one parsed.

Post a reply to this message

>
> Noone's talking about writing anything into POV.  We're talking about
> include files that come with POV.  The SDL would still exist in its
> current form.
>

A question of semantics. To me, if it comes as part of the package, it's
written in.  Yeah, it isn't a binary, but it's there when I download.

>
> overall user friendliness is an important aspect of
> design.
>

I agree with you, in that it should be easy for me to say what I want; I
don't want it to do things for me though. There is a big difference in my
mind between asking for a bunch of boxes and asking for a room.

> However, I've love to see a big green apple inside someone's
> eye, or some other artistic usage of the objects.  Having the objects
> available just means there is one less barrier between the artist and
> his final render.
>

It does seem, though, that some technical depth is required before that
artistic sensibility reaches it's prime. Picasso had to learn to draw
realistically before he was able to forget. Included objects are like
urinals. They're there, sure enough, but what does it take to sign one and
call it art?
I enjoy scribbles in crayon more than I do stencils and stamps, if that
makes sense. Cookie-cutter objects can be art (Worhol, Duchamp et al) but
it's not an easy trick to pull off. Crayon scribblings, well, they're not
perfect but they're always personal.

> > No, as an artistic community we cannot make this choice for technical ease.
>
> Why not?  Many artists are more concerned with artistic composition than
> technical creation anyway.
>

It seems unlikely to me that anyone would use something as (and I say this
in a loving way) asinine as pov if they weren't at least slightly invested
in the technical aspects of creation. Don't we often enough admire the code
just as much as the image?
[Thought: can the code of a scene lead the reader through that scene in a
narrative manner, adding a temporal element to a static scene? SDL =
self-illustrating literature?]

> You wouldn't have less primitive objects.  You'd have all the primitives
> you have now.  You would also have a large library of predefined
> objects, textures, finishes, media, etc to choose from.
>

Yes. I understand. But that library is composed of objects which are less
primitive.
Less, not fewer. Bad word choice on my part.


>
> Around a year ago I was woring on a scene for p.b.i. of a dandelion
> growing in a glass jar, on a windowsill.  Most of the work I did, was
> for the wall and a bottle.  I spent days working on them (status update:
> I lost the code :(, so if I ever return to it I'll have to start from
> scratch), when with a good object library I'd have been done in 5
> minutes.  Then, I could have spent the time on better things.
>
> I would love for this project to get off the ground, and I would
> definitely use the objects it provided.  Of course, there is a certain
> standard of quality: the key factor is that everything provided must be
> *worth* using, meaning we need not only high quality textures, but high
> quality CSG objects.
>

With a Canon Digital Rebel(r) and a 4-in-1 Photoprinter the Mona Lisa could
have been done in under 30 seconds a print --- but somehow it just doesn't
seem the same to me ;)

The POV-Ray community is a school of art, just like impressionism or dada.
Our manifesto is the set of bits that make up the latest distro. While that
inherently invites change, and we must embrace it as it comes, I do think
that part of the beauty that has been created comes from the challenge, the
intellectual pursuit of making a machine produce your vision. Ridding
ourselves of that inconvenience risks turning POV-Ray into so many
craft-store stencils.

Object libraries are fantastic for creating piles of stuff, backgrounds, for
lighting tests, for learning techniques and stealing ideas.  POV-Ray, when
used for academic pursuits, to render data or test vision systems, all that
sort of thing, doesn't need it. As an artistic medium, it just seems wierd
to me to include this. It's not even close to being an integral part of
what pov is; at best it's bit-clutter. Centralize it and when I need a duck
or (and?) a bowl of spaghetti, I'll come and get it.


Aah, what the heck am I whining about. Do whatever, of course. It's not like
I won't deal with it. It makes me darned uneasy, though.

--
Sam Bleckley
stm 31415 (at) g mail . com

Post a reply to this message

Charles C wrote:
> PPS, it'd be really cool if POV-Ray had a built in string constant named
> main_pov_file or main_scene_file or primary_sdl_file or something like that
> based on whatever file is the first one parsed.

this may have merit; note it is possible to declare that from an INI file or
command-line if you're rendering that way. that said it could be useful as an
automatic feature. perhaps more useful would be a file-specific boolean that
evaluates to true only if the main file is being parsed (e.g. is false in all
includes). I guess it should probably be true also during execution of any
macro that is called from the main file, even if it's declared elsewhere.

doing this may be tricky, as our symbol table doesn't work that way (it works
on nesting level like most do). if we had this we possibly also could have
SDL equivalents of the C language's __LINE__ and __FILE__ etc. (I suppose
there could also be some argument for predefined constants that tell you
whether or not radiosity is enabled, for example).

I'll leave you guys to toss all this around, be aware that I am not following
closely or reading each post. but I will state for the record that I am
prepared to at least consider changes that are of minimal impact to the
program (i.e. it won't delay 3.7 any further) _if_ those features will make
for a better object/include library /and/ they do not break the internal
design rules (e.g. backend is separate from frontend, parser is part of the
backend, hence frontend things such as display gamma etc don't belong in the
SDL).

-- Chris

Post a reply to this message

stm31415:
"Yeah, it isn't a binary, but it's there when I download."

Do you use any of povray textures in the include files?  No?  what are you
complaining about then?  Include files can be solemnly ignored if you don't
want them and want to build each scene anew from scratch using nothing but a
hex editor.

"There is a big difference in my mind between asking for a bunch of boxes
and asking for a room."

I never said that i would want, say, to simply do:
#include "places/interiors/kitchen/jvp.inc"
object { kitchen }

that is much worse than to simply render the .pov scene instead.  But it
would certainly be cool to have macros to create rooms and them populate
them with several objects common to certain locations, like kitchen or
restroom...

"Picasso had to learn to draw realistically before he was able to forget."

Include files can be solemnly ignored, i repeat.  If you're willing to learn
povray SDL, you can certainly do it.  I'm thinking of expanding the old pov
includes for people to quickly compose new scenes out of truly useful and
reusable parametrized object/texture creation macros.

"Included objects are like urinals. They're there, sure enough, but what
does it take to sign one and call it art?"

It's not art at all.  even in an exposition by some celebrity...

"It seems unlikely to me that anyone would use something as (and I say this
in a loving way) asinine as pov if they weren't at least slightly invested
in the technical aspects of creation."

Include files can be solemnly ignored, i repeat.

"Don't we often enough admire the code just as much as the image?"

I certainly do.  Specially the ones from Paul Bourke's Short Code Contest.
:)

"[Thought: can the code of a scene lead the reader through that scene in a
narrative manner, adding a temporal element to a static scene? SDL =
self-illustrating literature?]"

Yes.  It's not different actually from any other code, like programming
languages or musical notation.

"But that library is composed of objects which are less primitive."

As far as i understand, you're opposing the idea of a more modern library
because either you will not be able to learn povray SDL otherwise or
because such objects  won't cater to your taste, because they're to
specific and limited exactly for not being primitives.  Does is summarize
your points well enough?

So, let me state it for the last time:  include files can be solemnly
ignored.  Use SDL primitives and your own include files if you are feeling
creative.  Use predefined objects if you're feeling practical.

"With a Canon Digital Rebel(r) and a 4-in-1 Photoprinter the Mona Lisa could
have been done in under 30 seconds a print --- but somehow it just doesn't
seem the same to me ;)"

it isn't:  if it didn't exist, your camera and light would do no better than
having a pov scene of just a camera and light.  Some Joe Average using
povray for the first time rendering a scene with elements from Gilles
Tran's "Wet Bird" is the same as some Joe Average taking a shot from
Monalisa and photoshopping it.

"The POV-Ray community is a school of art, just like impressionism or dada.
Our manifesto is the set of bits that make up the latest distro. While that
inherently invites change, and we must embrace it as it comes, I do think
that part of the beauty that has been created comes from the challenge, the
intellectual pursuit of making a machine produce your vision. Ridding
ourselves of that inconvenience risks turning POV-Ray into so many
craft-store stencils."

Nice speach.  The Persistence of Vision name indeed hints at that.

But include files do not prevent that at all.  They are essentially there to
allow for a more industrial model than the handcraft model artists like so
much.  Handcraft artists will continue handcrafting scenes despite anything
we cram into povray include files.  It's my belief the main benefits from
such a facelift to povray includes would be the architectural types into
CAD stuff...

"Centralize it and when I need a duck or (and?) a bowl of spaghetti, I'll
come and get it."

I think it was a complete waste of time to bring this topic up.  It is clear
that as it is, povray catters mostly to people who enjoy handcrafting scenes
from scratch.  Is it because it comes so bare and naked?  The way i thought,
getting more useful stuff into povray include files would also make it more
attractive to people who want to reuse and compose rather than create.  The
way i see it, a more robust povray include library would only make it
stronger, without really coming in the way of handcrafters.

Chris, i'll work on this to get a more concrete example for people to
discuss, since most are arguing about a "standard" which really doesn't
exist.  Still, i'm not sure such a major facelift would be made just in
time for 3.7.  Perhaps 4.0? :)

Post a reply to this message

That this would be considered kinda makes my day.  I'd use it a lot.  I'd be
happy with any variation that works but it sounds like the quickest add-in
would be the original one suggested.  Anybody else have thoughts on this?
Charles


Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Charles C wrote:
> > PPS, it'd be really cool if POV-Ray had a built in string constant named
> > main_pov_file or main_scene_file or primary_sdl_file or something like that
> > based on whatever file is the first one parsed.
>
> this may have merit; note it is possible to declare that from an INI file or
> command-line if you're rendering that way. that said it could be useful as an
> automatic feature. perhaps more useful would be a file-specific boolean that
> evaluates to true only if the main file is being parsed (e.g. is false in all
> includes). I guess it should probably be true also during execution of any
> macro that is called from the main file, even if it's declared elsewhere.
>
> doing this may be tricky, as our symbol table doesn't work that way (it works
> on nesting level like most do). if we had this we possibly also could have
> SDL equivalents of the C language's __LINE__ and __FILE__ etc. (I suppose
> there could also be some argument for predefined constants that tell you
> whether or not radiosity is enabled, for example).
>
> I'll leave you guys to toss all this around, be aware that I am not following
> closely or reading each post. but I will state for the record that I am
> prepared to at least consider changes that are of minimal impact to the
> program (i.e. it won't delay 3.7 any further) _if_ those features will make
> for a better object/include library /and/ they do not break the internal
> design rules (e.g. backend is separate from frontend, parser is part of the
> backend, hence frontend things such as display gamma etc don't belong in the
> SDL).
>
> -- Chris

Post a reply to this message

Trolling through this thread, I think that to make this happen we need to
settle:

 o  Whether to bundle with POV-Ray vs. Separate Archives
 o  Policy for Licensing/Copyright/Release Notices
 o  Organisation/Taxonomy/Management
 o  Standards & How to maintain Object Diversity

From the discussions so far, it seems that we're close to a concensus on 
whether we try to add this into the POV-Ray download or whether we implement 
a separate area for downloading objects and stuff.. If this idea works well, 
this collection may become quite big and could generate frequent updates. 
Despite improvements in download
speeds, it could become too much to load into the POV-Ray standard download 
and would be easier to organised in a separate area set up on povray.org as 
Chris Cason has offered.

Unless anyone is vehemently opposed to this, then I'd suggest we start
separate threads to reach agreement on each of the other issues.

Regards,
Chris B.

Licensing/Copyright -
There are quite a few include file and object sites already, but
I always have a problem trying to work out whether stuff is truly re-usable
from a licensing perspective. Some include files come with licensing
information, but more often than not they just don't say or, even if they do
it's often difficult to keep track of which objects came with which license.
You don't always know how you'll want to use your scene in the future, so I
generally steer clear of using objects from the Internet altogether. I think
that having an area on povray.org where all of the contributions can be
re-used without any preconditions (or with a very minimal agreed standard
set) would be good and would make an important differentiator for this over
other object and include file sites. This would also mean that the POV-Ray
community could enhance these contributions over the years without having to
get permission from previous contributors who may now be uncontactable.

Organisation/Taxonomy -
This is likely to be tricky, because POV-Ray covers everything in the
Universe and then some.
I'd like to see a relatively small number of large archives covering areas
of interest. For example, my POV-House include files could be bundled with
household objects in a way that would enable the objects to be used
independently or in conjunction with the macros. We'd need either a taxonomy
of objects or a search capability to enable you to find out where individual
objects of interest to you are stored. Maybe we could have small groups
managing each area of interest.

Standards -
I think we'll need some. Otherwise two different include files
could easily interfere with each other. However, I'd advocate keeping the
standards to a minimum. I believe they should cover naming conventions and a
few other basics, but even there, we could have an indicator on the web site
to show which files adhere to the standards, so that older and non-compliant
files could still be published there, but users would be forewarned about
maybe having to sort out conflicts.

Object Diversity -
My approach to avoiding having all staircases or all houses or
people generated looking the same is to make as much as I can parameter
driven ,as well as enabling the component parts to be readily replaced. For
example, I try to use #ifdef() wherever I can and only define default
objects and textures for components that have not been explicitly defined by
the person using the include file. Rather than writing that sort of thing
into our standards, I would propose that we assemble (or reference if some
already exist) a few tutorials that illustrate how to build include files
that enable a diverse range of objects to be generated.



"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in
message news:4559b8d6$1@news.povray.org...
>
> 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 don't deny the standard scenes and includes could be supplemented
> usefully,
> perhaps as an additional download (or included with the standard one - I
> think people are a bit less worried about download sizes now than they
> were
> ten years ago).
>
> In terms of an object collection, while it's something I'd love to see, to
> do
> it properly would probably require that we have some sort of standard
> means
> to 'encapsulate' an object. By that I mean that if you want to for example
> '#include "kitchensink.inc" in your scene, it would help if the way you
> /use/
> the kitchen sink is standardized, with respect to the initial size,
> placement
> and so forth. Another possibility is to have some standard 'knobs' that
> all
> such objects share (where 'knobs' are a set of predefined SDL variables
> that
> can be set prior to the #include, or passed in the macro call if
> applicable).
>
> I have some other ideas for objects, too, but that's not for now.
>
> If the community wanted to work together to come up with a system that
> would
> smoothly integrate with other people's workflow by providing some
> standards
> such as this I'd be quite prepared to support it by setting up a site for
> it
> and providing whatever hosting support is needed.
>
> -- Chris
>   POV-Team

Post a reply to this message

Whoops, I hit the Send button before I meant to.
Please ignore everything after the signature in my previous posting (for 
now).

Regards,
Chris B.

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> Whoops, I hit the Send button before I meant to.
> Please ignore everything after the signature in my previous posting (for
> now).

Regardless of any anticipation, i'm glad to have put people to actually give
a good thought on the subject, like your post seems to hint.  Once you
better structure your ideas, i'll comment further...

regards

Post a reply to this message