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