|
 |
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] deletethistoo povrayorg> 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
|
|
|
|
"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
|
|
