 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] cs com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
