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