 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well here's my first attempt at summarising this thread. I've tried to pluck
out the ideas that we can do right now (i.e. that don't depend on parser
changes). I've selected what I think are the simplest of the ideas and built
them into what I'd propose as a cohesive starting point.
Some of the discussion points covered ideas that I think fit better into
'best practice' tutorials and guidance notes. I've set them aside for now,
but I think we should probably host such tutorials/guidance on the web site.
Some of the things that I've considered to be in this category include the
idea to have one object per file, positioning objects at the origin and 'y'
being 'up'.
Naming Conflicts
-----------------
I think the most important thing to address will be to avoid naming
collisions for files and identifiers. The simplest way of doing this will be
for contributions to adhere to naming standards based upon a name chosen by
the contributor. The name should be indicative of the content or purpose of
the contribution. Once a name has been chosen, no other contributions can
bear the same name, although clearly a particular contribution could be
changed almost beyond recognition over time by successive editors. Prefixes
will need to be used for file and identifier names (macros, variables,
functions etc).
The full contribution name could be used as the prefix. I think we should
also permit a shortened code to be used, but this would also need to be
unique.
Imagine someone creates a model of some cricket stumps and elects to name
the contribution 'CricketStumps'. If they wish to make use of a short code
and 'CS' has not already been used then they could register it. For this
example though, lets assume that 'CS' has already been allocated so they end
selecting 'CS2'.
Adherence to Naming Standards
---------------------------------
Use of the naming standards will be mandatory for contributions destined for
inclusion in the 'standard' part of the collection. As part of the
submission process the contributor will be required to indicate whether they
consider they have adhered to the standards. The contribution initially goes
into the 'ad-hoc' area. We could implement a 'feedback' screen where anyone
could comment on a contribution, with an option to dispute that a
contribution adheres to the standards.
If a contribution does adhere to the standards it could be promoted through
into the 'standard' area. Otherwise it will remain in the 'ad-hoc' area.
Such non-standard contributions would still be available for download, but
would be clearly 'marked' by the server to warn people that they don't
adhere to the standards (and to help prompt people to rectify the problem).
File Names
-----------
There's a limit on the number of directories we can declare in the library
path, so downloaded #include files and accompanying files will normally need
to go into just one directory - probably the include directory. Each of the
files from the collection that is going to end up in this directory will
therefore need to be uniquely named. Actually, I think that even if we use
an alternative directory or multiple directories in some way the names would
still need to be unique.
A contribution could contain multiple files, but all files in the
contribution will need to be made unique by using a common designated
prefix.
It probably be easiest to implement if the files all use the contribution
name as a prefix. This would make it easier for automated routines on the
server to manage parts of a contribution. The server could look for files
called:
o CricketStumps.html - as the top-level documentation file for the
contribution
o CricketStumps.keywords - for use with the search facility
o CricketStumps.pov - if present, could contain a simple renderable
example of the object
o CricketStumps.inc - would be the main include file and could also be
renderable
o CricketStumps.jpg - could contain a 800x600 render from which the server
could generate a thumbnail.
Other files could be included in the contribution, so, if the contribution
had its own separate texture file it could be called
CricketStumps_Textures.inc. None of these files would be mandatory, but if
not provided, the 'keywords' file would be created based on keywords entered
into the upload page when the collection is submitted.
If we permit an abbreviated prefix to be used then file names could become
CS2.inc, CS2_Textures.inc etc and the server would need to be able to
recognise that they are part of the same contribution. Maybe we'd have a
server generated file named CS2.CricketStumps to make the relationship
between the name and the prefix clear to a user looking through their
include directory.
If the contribution name needs to be followed by a descriptive name it
should be separated using an underscore e.g. CS2_Textures.inc or
CricketStumps_Textures.inc.
Does anyone know of any operating system of transfer software issues with
mixed case letters that may make it more sensible to use all lowercase file
names?
Identifier Names
----------------
In order that people will be able to use multiple contributions within a
single POV scene, identifiers declared in the include files will need to be
uniquely named so that they don't get mixed up with identifiers declared in
other include files from the collection and with those used in the scene
file.
The declaration of a variable intended to permit someone using the
CricketStumps contribution to set a height for some stumps may therefore
become '#declare CS2_StumpHeight = 0.85;'. Using an underscore here helps
anyone who may need to rename a set of identifiers in the future, for
example, anyone wishing to re-use a macro originally designed for
positioning cricket stumps within a future contribution for creating a
picket fence could readily rename identifiers.
Where an identifier does not need to be exposed to the person using the file
it should be declared using the #local directive.
Macro and Function Names
----------------------------
Similarly Macro names and function names will need to be unique, and would
need to be defined using the same unique prefix. e.g.
#macro CS2_CreateStumps (CS2_BailsOnFlag)
...
#end
Problematic File Types
-----------------------
It would be desirable to be able to permit non-SDL based utilities to be
added to the collection, such as conversion utilities, but if executable
files are permitted we should consider the potential question of viruses.
First step will be to check whether there's a virus scanner available to
povray.org to enable automated scanning of submitted files.
Sizing Standards
----------------
There was a discussion about whether people should be required to use a
standard size such as 1 POV-Ray unit = 1metre, but I think the consensus was
that this would difficult to apply universally because very large scale
(e.g. galaxies) and very small scales (atoms) can't reasonably adhere to
such a standard. Furthermore, someone who is accustomed to working in
Imperial measures could find it difficult to think in Metric.
I think the idea of documenting the units either in comments at the top of
the file or in the accompanying documentation was the best and simplest
idea. The contributor should also be encouraged to document the position and
size of their object and to include a sample scene file that people can look
at to easily work out how to get the object into the camera frame.
There was a proposal to have some generic unit conversion mechanism to allow
contributors to use the units they find most appropriate, while enabling
people to readily mix-and-match #include files.
This could be a macro or just some variable declarations and we could do
both very easily. I see Charles has started off a macro. We could also
create a standard #include file containing simple variable declarations
using a standard naming format:
#declare inches2metres = 0.0254;
#declare inches2feet = 1/12;
#declare miles2kilometres = 1.609344;
#declare feet2metres = 0.3048;
#declare metres2inches = 39.37007874;
#declare feet2inches = 12;
#declare kilometres2miles = 0.621371192;
#declare metres2feet = 3.280839895;
#declare lightyear2parsec = 0.306391546;
#declare parsec2lightyear = 3.263797626 ;
... etc ...
Then, if an object was defined in metres and we wanted it in feet we'd just
'scale metres2feet'.
We could even merge both ideas into a single include file, which could maybe
even find its way into the standard POV-Ray includes directory with V3.7 or
4.
Other Stuff
-----------
I'm sure that, over time, some clever people will develop utilities and
techniques to help improve standardisation of contributions, for example, a
parser to read a non-standard file and write out a standard one, ways of
wrapping non-standard code to make it look standard and changes to the
POV-Ray parser to introduce namespaces were all discussed.
If this all suits eveybody then I'd suggest that we plough ahead using an
approach that's as straight forward as possible to get this off the ground
and to see how it flies.
Anything I've missed, or that you disagree with?
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:4587c656$1@news.povray.org Chris B wrote:
> There was a discussion about whether people should be required to use
> a standard size such as 1 POV-Ray unit = 1metre, but I think the
> consensus was that this would difficult to apply universally because
> very large scale (e.g. galaxies) and very small scales (atoms) can't
> reasonably adhere to such a standard. Furthermore, someone who is
> accustomed to working in Imperial measures could find it difficult to
> think in Metric.
>
Sorry, I wasn't able to follow all the discussions recently, so my
comment may have come up. Instead of standardising units why not require
a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
user can scale the object to fit in a scene. For large scale objects one
could recuire it to fit in a 100x100x100 unit box. Or require that the
container for every object is defined in the #includefile (eventhough it
can be figured out using min/max_extent)
Thanks for the summary Chris.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tag povrayorg> wrote:
> Instead of standardising units why not require
> a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
> user can scale the object to fit in a scene.
Btw, there's one thing to consider when predeclaring an object which is
later to be scaled:
Media density is not scaled with the object.
There are two possible behaviours of media density, both of which have
their rationale:
1) It is not affected by 'scale' (as it currently isn't). This is logical
when you think about an example case: If you have a glass of colored water,
it will filter light passing through it by some amount. If you take a glass
of the same colored water but which is twice as big, it will filter *more*
the light passing through it (because the light now traverses a larger
distance through the water). This is how POV-Ray currently behaves.
2) Density is affected by scale. This would be useful if you want to
eg. scale the entire scene to a different size, while keeping it looking
exactly the same. In other words, you might want to make everything 10 times
bigger (including the camera location etc), after which everything should
look identical, just all internal values are now ten-fold.
However, if you have an object with media in it, its density will currently
not be scaled, and you will end up with a much stronger media density, and
thus the object in question will look very different (with a 10 times
stronger media).
POV-Ray currently behaves as 1), but if you want the 2) behaviour, you'll
have to manually scale the media density by the inverse of the object scale
(IOW. if you scale the object 10 times bigger you have to divide the media
density by 10).
This consitutes a small problem with a predeclared object in an include
file which has media inside it. If you just instantiate the object and
scale it, and what you want is for the media to look identical regardless
of scale, that won't do it.
But on the other hand, you might *want* the media density to not to be
scaled with the object in order to get a more realistic result in certain
situations (think of the glass with colored water).
One possible solution to this is to make such objects #macros, one of
which parameters is the desired scale of the object. The macro will then
inversely scale the density of the media. This way if the user wants the
density to be scaled, he gives the scale as macro parameter, and if he
doesn't want it to be scaled, he just gives a "1" as scale parameter and
scales the object in his own code.
(Combinations of both are of course possible too, such as when you want
differently sized colored water glasses, but the base scale of the scene
is very different from what the original object was sized to.)
Of course uneven scaling is an interesting question in its own, but
let's not go that deep, shall we?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:45881636@news.povray.org...
>
> Btw, there's one thing to consider when predeclaring an object which is
> later to be scaled:
> Media density is not scaled with the object.
>
> ... snip ...
>
> One possible solution to this is to make such objects #macros, one of
> which parameters is the desired scale of the object. The macro will then
> inversely scale the density of the media.
>
> ... snip ...
>
> - Warp
That's something I wasn't aware of, but I have come across another situation
where scaling, rotating or translating a generated object was problematic
and ended up having to 'tell' the macro about any transformation that was
going to be applied so that it could take account of it during the
generation of the object (using an inverse of the transformation).
I think we should build such examples into part of a tutorial on how to make
objects reusable.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B <c_b### [at] btconnectcomnospam> wrote:
> That's something I wasn't aware of, but I have come across another situation
> where scaling, rotating or translating a generated object was problematic
> and ended up having to 'tell' the macro about any transformation that was
> going to be applied so that it could take account of it during the
> generation of the object (using an inverse of the transformation).
Another feature which is not affected by transformations is the slope
pattern. However, I believe this to be a bug in POV-Ray which may be fixed
some time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4588219a@news.povray.org...
> Chris B <c_b### [at] btconnectcomnospam> wrote:
>> That's something I wasn't aware of, but I have come across another
>> situation
>> where scaling, rotating or translating a generated object was problematic
>> and ended up having to 'tell' the macro about any transformation that was
>> going to be applied so that it could take account of it during the
>> generation of the object (using an inverse of the transformation).
>
> Another feature which is not affected by transformations is the slope
> pattern. However, I believe this to be a bug in POV-Ray which may be fixed
> some time.
>
> --
> - Warp
Hmm. So some sort of 'health warning' in a tutorial would probably be in
order for that one :o)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] tagpovrayorg> wrote in message
news:Xns989EACFFCF424seed7@news.povray.org...
> in news:4587c656$1@news.povray.org Chris B wrote:
>
>> There was a discussion about whether people should be required to use
>> a standard size such as 1 POV-Ray unit = 1metre, but I think the
>> consensus was that this would difficult to apply universally because
>> very large scale (e.g. galaxies) and very small scales (atoms) can't
>> reasonably adhere to such a standard. Furthermore, someone who is
>> accustomed to working in Imperial measures could find it difficult to
>> think in Metric.
>>
>
> Sorry, I wasn't able to follow all the discussions recently, so my
> comment may have come up. Instead of standardising units why not require
> a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
> user can scale the object to fit in a scene. For large scale objects one
> could recuire it to fit in a 100x100x100 unit box. Or require that the
> container for every object is defined in the #includefile (eventhough it
> can be figured out using min/max_extent)
>
> Thanks for the summary Chris.
>
> Ingo
Hi Ingo,
I think it was touched on in the thread, but I don't think it was discussed
in detail.
Personally I think this would make life more complicated rather than less.
When I think of my POVPerson macros which generate characters of different
sizes in different poses, if the macro scaled a 6ft tall seated person to
fit in a fixed sized unit cube and then, on a second call to the macro it
scaled a 5ft 4in standing person to fit in the same sized cube, I think it
would make the characters quite difficult to use. The person using them
would have to scale them up again by some quite difficult to calculate
amounts to be able to use them together.
Even with something as simple as a cricket ball, you'd have to know the size
of a cricket ball to scale it back to a realistic size if you just get a
unit sized ball, whereas, if it's in a recognised unit of measure you'd
probably be able to guess which conversion you need without even reading the
accompanying documentation. IMO if you had a ball in metres and a set of
cricket stumps in feet I think this would still be easier to work with than
if you got them both scaled to fit in a unit square.
As soon as you get larger collections of objects I think the problem would
grow. If each was scaled to a unit cube, then scaling them all by different
amounts to get them to work together seems to me like it would be a real
pain.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tagpovrayorg> wrote:
> comment may have come up. Instead of standardising units why not require
> a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
> user can scale the object to fit in a scene.
Yes, i've come up with that earlier, i think in another thread. It makes a
lot of sense to me and i feel glad that someone else also likes the idea.
:)
I've been busy these days, and since Christmas is close, i don't think i'll
have much time for these lengthy discussions. How about saving it for
January? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
