 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2007 14:48:52 -0400, Alain wrote:
> Jim Henderson nous apporta ses lumieres en ce 2007/09/26 13:48:
>> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
>>
>>> Positive point: this simplify things for some peoples. Negative point:
>>> this imply several HUGE libraries of premade shapes, textures,
>>> environments, models,...
>>> Another negative point: Humongous code bloat. How about a 5+ Gb
>>> download?
>>
>> Bottom line point: I think it's safe to assume that Bryan was making a
>> joke. ;-)
>>
>> Jim
> I agree, let just assume it IS a joke ;-)
What I want to know is why he only went a 9.5 on sexiness....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Warp:
> Here are some ideas of mine
As good a place as any to start. I want to contribute to this discussion
as someone who is not a knowledgeable programmer but has possibly
written at as much POV SDL code as any other person on this server.
I have put some thought over the past two weeks into deciding what
exactly POV-Ray is. A renderer of course; A modeler perhaps. But, beyond
that, what is POV-Ray in relation to other "free" renderers out there?
My conclusion is that POV-Ray is, importantly, the renderer whose users
best understand it. Here's an example: I asked on the Yafray forum
whether Yafray allowed a user to explicitly define the vertex normals of
a mesh; 165 views so far - 0 answers. No user on the forum seems to
know. Blender can't do it, so Blender's limitation has become, literally
or practically, Yafray's limitation. Contrast this with the POV-Ray user
base, the even moderately experienced of which are familiar with both of
our mesh formats, light_groups, no_image, and many other critical
features which the mouse-modeler crowd might consider merely "tweaks."
Given that, what can and cannot be changed without changing POV-Ray's
identity?
> Warp:
> * Even if it's based on the current SDL <snip> some backwards-
> compatibility must be broken
Must be based around certain characteristics of the current SDL. A scene
with a camera, light_source, and sphere must require familiarity only
with the camera, light_source, and sphere objects. There should never be
a section in the documentation titled, "Structure of a POV-Ray Scene
File" or anything similar.
Forget backwards compatibility. Now is the best opportunity that will
likely ever come to undo any "mistakes" of the past.
> Warp:
> * Existing data containers, namely arrays and strings (which are
> special arrays of characters), should be enhanced and new data
> containers introduced <snip> it may be necessary to introduce the
> concept of modules (ie. classes without inheritance) or classes
> (with perhaps a simple inheritance support) and references. These
> modules or classes could have member variables and perhaps even member
> functions. Accessing the elements could be done with the dot operator.
All of this would add piles of pages to the documentation (a bad thing),
and provide (in most cases) nothing which could not be provided by
generating SDL with any given user's programming language of choice.
The way I work now is by generating POV SDL in Python, but I still make
use of POV-Ray macros. An example is a macro which uses eval_pigment.
POV-Ray knows the value of "leopard" at <3,4,5> - Python doesn't.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Any addition to the procedural part of POV SDL must either be necessary
to create a scene, significantly decrease the size of a scene-file, or
significantly increase the readability of a scene-file.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Warp:
> * The most difficult thing of all: Some kind of shader language,
How about keeping it simple? For instance, a function "surface" which
knows what every ray knows and works with POV-Ray's existing texture and
finish options.
How a colored specular shader might look (if functions could return
vectors):
#local colored_specular = function {
pigment {
function { surface().specular }
pigment_map {
[0 object_pigment]
[1 rgb <1,1,0>]
}
}
}
sphere { 0, 1
pigment { rgb <1,0,0> }
finish { specular .8 }
shader { function { colored_specular() } }
}
A toon shader might make use of surface().illumination or
surface().angle_of_incidence
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cc cc> wrote:
> All of this would add piles of pages to the documentation (a bad thing),
A bad thing why? You don't have to read those parts of the documentation
if you don't want to. You don't have to use the extra features if you don't
want to. But why would you want to remove the extra features from people
who could create awesome things with them?
Imagine you could write this scene in POV-Ray:
#include "import3ds.inc"
import3ds("myscene.3ds");
And that's it. Nothing more. And the scene renderes beautifully.
But no, you don't want this. You want to remove any possibility of
doing this. You want to keep POV-Ray simple and dumb, without any tools
to actually make it more versatile and powerful than it already is.
When some newbie asks "can I convert a 3DS file to povray" you will
answer the old same "try this converter software which does a half-assed
job and might work or not".
Making povray simpler and dumber is only going to hurt it.
> and provide (in most cases) nothing which could not be provided by
> generating SDL with any given user's programming language of choice.
How would you generate a shader which accesses a data container with
an external programming language if povray does not support that?
> > * The most difficult thing of all: Some kind of shader language,
> How about keeping it simple? For instance, a function "surface" which
> knows what every ray knows and works with POV-Ray's existing texture and
> finish options.
Why keep it needlessly simple when you could just as well write the
shader with the exact same scripting language you are creating the
scene with?
What if you wanted to write a shader which, for example, spawns
additional rays? Or one which gives different results depending on
whether it's inside or outside a specific object?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 26 Sep 2007 14:48:52 -0400, Alain wrote:
>
>> Jim Henderson nous apporta ses lumieres en ce 2007/09/26 13:48:
>>> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
>>>
>>>> Positive point: this simplify things for some peoples. Negative point:
>>>> this imply several HUGE libraries of premade shapes, textures,
>>>> environments, models,...
>>>> Another negative point: Humongous code bloat. How about a 5+ Gb
>>>> download?
>>>
>>> Bottom line point: I think it's safe to assume that Bryan was making a
>>> joke. ;-)
>>>
>>> Jim
>> I agree, let just assume it IS a joke ;-)
>
> What I want to know is why he only went a 9.5 on sexiness....
>
> Jim
Any value higher then 9.5 could be considered by some as being of a too
profound sexual nature, and this is still a public access server.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 26 Sep 2007 08:57:39 -0400, Alain wrote:
>
>> Positive point: this simplify things for some peoples. Negative point:
>> this imply several HUGE libraries of premade shapes, textures,
>> environments, models,...
>> Another negative point: Humongous code bloat. How about a 5+ Gb
>> download?
>
> Bottom line point: I think it's safe to assume that Bryan was making a
> joke. ;-)
>
> Jim
LOL - absolutely. POV is not about making beautiful images easily.
It's about empowering people who have no ability to paint or draw to
make art!
I personally sketch like a 4th grader - and I find that my perceptual
mind cannot flatten itself to make a 2D image out of what is really a 3D
object such as a face, a car, a flower, etc.
Just to emphasize: I have never seen a great piece of POVray art that
could not have been done in far less time by an accomplished painter.
But you're right - I was joking. Art can never be generalized enough to
make it like my example. It it ever did get like that, it would no
longer be art.
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
>
> What I want to know is why he only went a 9.5 on sexiness....
>
> Jim
Because I'm not a big Bo Derek Fan.
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2007 13:34:22 -0700, Bryan Valencia wrote:
> Jim Henderson wrote:
>>
>> What I want to know is why he only went a 9.5 on sexiness....
>>
>> Jim
>
> Because I'm not a big Bo Derek Fan.
Well, I wouldn't rate her a 10. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 26 Sep 2007 15:10:26 -0500, Ger wrote:
> Any value higher then 9.5 could be considered by some as being of a too
> profound sexual nature, and this is still a public access server.
Hmm, that's a fair point. :_)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Shay:
>> All of this would add piles of pages to the documentation
>> (a bad thing),
> Warp:
> A bad thing why? You don't have to read those parts of
> the documentation if you don't want to.
Because it will make it more difficult for an average user to find tools
which may be of critical use to him. There are many great features of
POV-Ray which a person would never know to look for - luckily the entire
index of the POV-Ray documentation is still small enough to browse, so
these features are not "lost."
> Warp:
> You don't have to use the extra features if you don't want
> to. But why would you want to remove the extra features from
> people who could create awesome things with them?
I do want extra features. I don't want to clutter up the SDL with
shortcuts. I don't want POV-Ray to become the Emacs of renderers. I do
believe in adding what is absolutely needed for bi-directionality. I
don't believe that the ability to make pretty subdivision macros or text
converters in SDL is worth the cost.
"Yes!" to all that is necessary; "No!" to all that is merely convenient.
> Warp:
> Imagine you could write this scene in POV-Ray:
>
> #include "import3ds.inc"
> import3ds("myscene.3ds");
>
> And that's it. Nothing more. And the scene renderes beautifully.
>
> But no, you don't want this. <snip> When some newbie asks "can I
> convert a 3DS file to povray" you will answer the old same "try
> this converter software which does a half-assed job and might work
> or not".
And by what magic will a converter written in SDL be less half-assed?
> Warp:
> How would you generate a shader which accesses a data container
> with an external programming language if povray does not support
> that?
from the post to which you are replying:
"Any addition to the procedural part of POV SDL must either be necessary
to create a scene, ..."
I am not advocating not expanding the language.
> Warp:
> Why keep it needlessly simple<snip>?
If you're going to make a program capable of producing print-quality
work, then you'll want as many people as possible using the program for
that purpose. I'm sure you'll agree that there is a point of diminishing
return...
> Warp:
> What if you wanted to write a shader which, for example, spawns
> additional rays?
...The question is whether such ability lies before or after that point.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Shay wrote:
> I do want extra features. I don't want to clutter up the SDL with
> shortcuts. I don't want POV-Ray to become the Emacs of renderers.
Pov-Ray became the Emacs of renderers a long, long time ago. :-)
God knows that I am not a fan of syntactic sugar, but what Warp is
suggesting is not syntactic sugar. He is suggesting making it *possible*
to do things in Pov that currently have to be done in an ad-hoc way
outside of Pov before/after a render. Unless you run an operating system
Designed The Way Operating Systems Should Be Designed (Unix or Linux),
automating this stuff is a royal pain.
Honestly, that's how I see Pov: an environment for automating and
scripting graphics creation. Take that away, and it's just one of the
many, many raytracing packages out there.
...On the other hand, I will lart anyone who suggests adding a mail
reader to Pov. :-P
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you find yourself having a
Web surfing cycle of two months: http://www.irtc.org/ is what caused that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG+tFecCmTzQ++ZncRAo6IAKCwOohDMToH5zsafymY16Kkkn8REwCZAW0/
P0F4p0ndl6jS5hAwtrEX3RA=
=SEjp
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> Just to emphasize: I have never seen a great piece of POVray art that
> could not have been done in far less time by an accomplished painter.
I disagree. Although such images may be *copied* in less time in paint
(and even faster using a camera), most/all of them would never have been
created if one were restricted to paint only. The whole process of
creation is totally different. I am not claiming to create art (I even
have a letter from the arts committee in our hospital that I don't) but
I know that for me it is impossible to think in only 2 dimensions. So,
nothing that I created could have been done with either oil on canvas or
with photoshop.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I used to use POV because it was what was available. Now I use POV because
it's capable of running standalone, it's fast for many things (compared to
much of the competition), the source is available for modification, and the
SDL is nice and straightforward (although some of the workarounds for
rendering problems aren't).
If any of those change, I would have to switch to another renderer.
For me, the main irritations at the moment are: the speed of parsing
triangle meshes and the rendering defects thereof, plus the lack of a
fully-featured shading language. Not really anything to do with the SDL
itself, although I vote for getting rid of the "#" from declarations as
well.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> I
> don't believe that the ability to make pretty subdivision macros or text
> converters in SDL is worth the cost.
What cost? I really don't understand you.
Let's see that I understand you correctly: You abhor the idea of adding
flexibility features in povray which would allow, for example, creating
subdivision libraries, and the reason for this is that this would cause
some new items to be added to the table of contents of the documentation?
That just doesn't make any sense at all.
> "Yes!" to all that is necessary; "No!" to all that is merely convenient.
Well, then let's remove every "convenient" thing there is in povray and
make it as hard to use as possible.
> > But no, you don't want this. <snip> When some newbie asks "can I
> > convert a 3DS file to povray" you will answer the old same "try
> > this converter software which does a half-assed job and might work
> > or not".
> And by what magic will a converter written in SDL be less half-assed?
Not by magic. By a community.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I Think there is some confusion between WHAT we want this new SDL to be and
HOW it will take form and be implemented. It is always prematurate to
answer the second question before aswering (more or less) the first. We
should focus on defining WHAT (and WHY) we want this or that feature.
Here are some questions/suggestions that could concern the 'WHAT' and that
pop up in my mind while typing, maybe some are nonsense:
Meta-features
Would it be rather script-oriented, programming laguage-oriented, or a
whole development environement?
Modularity/Reusability/Evolutivity
Interoperability with other systems/formats
Distributed render
Collaborative scene development and repository (POV-forge?)
Documentation
Debugger
Preview of object/textures being defined
Related Tools?
.../...
Features
Keep current POV (+MegaPOV?) features
Improve some (JIT-compiler for isosurface functions?)
Add some object types (primitive/compound)?
MegaPOV's (cloth, mechsim, glow, hdr ...)
Sub-surface scattering
Landscape-oriented: terrain, skyscape, clouds, sun, rain, snow, ...
Vegetation-oriented (tree, ivy, flower, grass, ...)
Characters/Animals/Organic (articulated=> IK?), skin, cloth, hair
Fires/smokes/explosions
Particle system (running liquids, ...)
.../...
Built-in object placement
drop_on (Object),
stick_on (Object),
throw (Direction),
.../...
Animation features
Paths
Morphing (meshes)
Timelines attached to objects
Collision detection
Object breaking/explosion
.../...
Syntax
Keep syntax for objects/pigments/... nor far from what it is now
Rather object-oriented or rather functionnal-oriented?
Get inspired by existing languages? (for me: yes)
Compact yet readable
Specialized 'editor' or only syntax-colored text editor?
.../...
Perhaps we could imagine a way to collect and formalize ideas and
requirements from the community, and then organize/hierarchize, and then
submit/comment.
Some of us can volunteer to help on this task (like some did for TC-RTC).
A new-SDL comitee can be chosen.
Every one can contribute (stupids/newbies/advanced/gurus).
POV-team as main advisor and decision-maker.
I repeat here at the end of this post: WHAT do we want? The 'HOW' should be
answered later, taking into account technical aspects and feasibility,
development cost, time cost, money cost (we will probably have to provide
the
development team with new tools, docs, aspirin, coffee, therapists or
whatsoever :O))
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message
news:web.46fbd573e7dc7428e8ba46670@news.povray.org...
<snipped but read with enthusiasm>
Excellent post Bruno! That brought it all together for *me* as it was
getting a little confusing! ;)
> Every one can contribute (stupids/newbies/advanced/gurus).
If there's any modelling that needs doing, I'm all for it. I think I'm
getting to be a dab-hand with Wings now, (and so are others, I've noticed),
and I know I can do what's asked for.
Anyway, I'm here if needed, no problem.
~Steve~
> Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27.09.2007 18:41, St. nous fit lire :
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message
> news:web.46fbd573e7dc7428e8ba46670@news.povray.org...
>
> <snipped but read with enthusiasm>
>
> Excellent post Bruno! That brought it all together for *me* as it was
> getting a little confusing! ;)
>
>
>> Every one can contribute (stupids/newbies/advanced/gurus).
I'm always afraid of "designed by committee"
http://en.wikipedia.org/wiki/Design_by_committee
pov SDL is not that orthodox (a little bit more of absolut orthodoxy
in its concept could really help the learning curve of beginners),
but I have always ponders that issue with backward compatibility.
If I was to change the parser and the data structure, I would limit
myself to make the same capability for finish than for normal and
pigment, and drop the texture. And change the model for color
(separating filtering pigment from ray-data, so as to be able to
process ray's color with a matrix [changing the wavelength when
hitting a surface, in any way you can thing of]) to an open-model
which could play Grey-only, RGBa, as well as discret spectrum (or
anything you can thing of).
All the details at http://jgrimbert.free.fr/crayon.pdf
(in french, have a look at the UML if you cannot read it...most
complex is on page 40.)
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Well, then let's remove every "convenient" thing there is in povray and
> make it as hard to use as possible.
The point on which we disagree is the nature of convenience or
usability. The relationship between feature expansion and usability has
been argued a thousand times - there's no point in continuing to repeat
it. If you think a large expansion of the (already buggy) procedural
portion of POV SDL is the most convenient (to users) way to accomplish a
job like format conversion, then so be it. I think you're nuts. I say,
learn a little Perl (that's what it's there for), or even better,
hard-code format conversion into the POV source code. I guess that
sounds nutty to you.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
Warp, thanks for the well thought out and measured set of suggestions.
If nothing else you put the discussion on a more organized plane with
a good marriage
of abstract concepts and specific examples
>
> #macro M(a, b)
> , a, b>
> #end
>
> sphere { <1 M(2, 3), 4 }
>
> This just doesn't fit in for byte-compiled code (at least not with very,
> very ugly hacks which would only burden and slow down the VM interpreting
> the bytecode).
> The vast majority of #macros out there already work as pure functions,
> though, so only the "ugliest" ones would break.
I gotta laugh, naturally *I* do those sorts of ugly things all the time.
But hey, I wince when I do it. Guess I could live with a little more
enforced rigor.
( I usually find I reach for the #macro command and get into that kind
of trouble when I am looking for some way to introduce rand() into the
works. But I digress)
>
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.
> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.
> Strings could also be internally implemented as C++ strings. This would
> also allow easy resizing and appending. Also any byte values should be
> supported so that strings could also be used as raw byte arrays (for example
> for reading and writing files in binary mode). More operators and functions
> for accessing and manipulating strings should be added.
That would be *Wonderful!*
>
> Some syntactical technique should be introduced which would allow handling
> and accessing other types of data containers as well, such as lists and
> sets (balanced binary trees). Using the same idea as with C++ iterators for
> this could be one possibility. This would allow offering the C++ data
> containers at the SDL level.
Over my head but still sounds great. What I like about Python, what
ever its weaknesses, is the easy string handling.
>
> * The language should be enhanced in such a way that you can create your
> own (efficient) data containers. For this it may be necessary to introduce
> the concept of modules (ie. classes without inheritance) or classes (with
> perhaps a simple inheritance support) and references. These modules or
> classes could have member variables and perhaps even member functions.
> Accessing the elements could be done with the dot operator.
Over my head, but if it would keep the heavy tech boys interested, I'm
all for it. We need to keep you guys interested.
>
> * Many of the existing features of the current SDL, such as the camera,
> global_settings, etc, could be enhanced to behave like such modules/classes.
> For example, I envision this kind of code being possible:
>
> #if(global_settings.max_trace_level < 10)
> global_settings { max_trace_level 10 }
> // or alternatively: global_settings.max_trace_level = 10
> #end
>
> #declare CameraAngle = camera.angle;
>
> Perhaps even objects could behave like modules/classes like this, so
> you could do something like:
>
> #declare S = sphere { 0, 1 };
> #declare R = S.radius;
>
> This could be especially useful for writing SDL libraries which modify
> triangle meshes (eg. subdivision, smoothing...)
This would be great.
>
> * There should be support for binary reading and writing of files (into
> strings, which have been enhanced to support raw byte data). Maybe other
> methods of reading and writing files could be introduced as well (in order
> to make it easier to write file format parsers).
>
> * If possible, introduce alternative ways of handling identifiers/variables
> so that all of these lines are valid:
>
> #declare Var = Var + 1;
> Var = Var + 1;
> #declare Var += 1;
> Var += 1;
Could make for a debugging nightmare... Gestalt psychology, training the
'eye' and all that. Your eye is used to C++ so naturally you would like
to gravitate there. I find the limited, though admittedly cumbersome,
POV look reassuring when I am about to tackle reams of code looking for
my one typo. But then again, most of us shift between languages where
that other syntax is supported so it may be a lame concern on my part.
>
> * The most difficult thing of all: Some kind of shader language, and deciding
> if this will be a completely separate language from the SDL (in the same
> way as current user-defined functions are) or if it will be the same.
> Perhaps a limited set of the SDL itself could be used as a shader language
> (for example a shader would be a macro/function which takes certain
> parameters and only uses a subset of the whole SDL, and which has access
> to certain special functions not accessible normally; the parser would check
> that this is so).
> Ideally such shader function could do things like trace additional rays,
> read information from objects, textures, etc.
>
Since we are undertaking the conversation. I would enjoy having you
sketch this out a little more. I hit a bump, conceptually, when I see
the term 'shader language'. I am not really sure what it means in
relation to the texturing that POV uses. You are usually pretty good at
sorting out these kind of semantic/conceptual tangles for us that are
less technical. For instance I thought that 'shader language' went
along with 'scanline rendering'
-Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> Warp wrote:
>
> >
> > Well, then let's remove every "convenient" thing there is in povray and
> > make it as hard to use as possible.
>
> The point on which we disagree is the nature of convenience or
> usability. The relationship between feature expansion and usability has
> been argued a thousand times - there's no point in continuing to repeat
> it. If you think a large expansion of the (already buggy) procedural
> portion of POV SDL is the most convenient (to users) way to accomplish a
> job like format conversion, then so be it. I think you're nuts. I say,
> learn a little Perl (that's what it's there for), or even better,
> hard-code format conversion into the POV source code. I guess that
> sounds nutty to you.
>
> -Shay
I have to say I like the direction Warp wants SDL to go... Most of my POV
coding is in the procedural portion and there are a lot MORE things I'd
like to be able to do directly in SDL. That's what makes POV-Ray useful to
me as opposed to *having* to turn to external things. The idea of making
source SDL which is usable to anybody who has POV-Ray is appealing. When a
project starts to require multiple languages, the number of people who'll be
able to use it starts to drop.
My thinking and my hope for in an updated SDL are largely what Warp
mentioned. Specifically, more use of the dot operator (even adding .xy
..xyz etc to for vectors), user definable data structures again with more
use of dot operators, more control, i/o for arbitrary binary files, and
better string manipulation.
One really specific thing I'd like: The currently-'experimental' but often
used feature, splines, I think would benefit from a new syntax - I think
that splines
should be treated as a basically/almost-normal array of 4d vectors.
MySpline(Value) would return a 3d vector point along a spline like is done
now. MySpline[Value] would return a 4d vector control point of the given
array-position in the form <x,y,z,t> where t is the float-position along
the spline's length. MySpline[Value].xyz would return a 3d version of the
control point. Transformations would apply to all values on the 'spline
array' except for the t values unless specifically called for by use of dot
operators.
Charles
PS (Woohoo! I was able to log on today from home with my high latency
connection!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote:
> Shay <Sha### [at] cccc> wrote:
> > Warp wrote:
> >
> > >
> > > Well, then let's remove every "convenient" thing there is in povray and
> > > make it as hard to use as possible.
> >
> > The point on which we disagree is the nature of convenience or
> > usability. The relationship between feature expansion and usability has
> > been argued a thousand times - there's no point in continuing to repeat
> > it. If you think a large expansion of the (already buggy) procedural
> > portion of POV SDL is the most convenient (to users) way to accomplish a
> > job like format conversion, then so be it. I think you're nuts. I say,
> > learn a little Perl (that's what it's there for), or even better,
> > hard-code format conversion into the POV source code. I guess that
> > sounds nutty to you.
> >
> > -Shay
>
> I have to say I like the direction Warp wants SDL to go... Most of my POV
> coding is in the procedural portion and there are a lot MORE things I'd
> like to be able to do directly in SDL. That's what makes POV-Ray useful to
> me as opposed to *having* to turn to external things. The idea of making
> source SDL which is usable to anybody who has POV-Ray is appealing. When a
> project starts to require multiple languages, the number of people who'll be
> able to use it starts to drop.
>
> My thinking and my hope for in an updated SDL are largely what Warp
> mentioned. Specifically, more use of the dot operator (even adding .xy
> ..xyz etc to for vectors), user definable data structures again with more
> use of dot operators, more control, i/o for arbitrary binary files, and
> better string manipulation.
>
> One really specific thing I'd like: The currently-'experimental' but often
> used feature, splines, I think would benefit from a new syntax - I think
> that splines
> should be treated as a basically/almost-normal array of 4d vectors.
> MySpline(Value) would return a 3d vector point along a spline like is done
> now. MySpline[Value] would return a 4d vector control point of the given
> array-position in the form <x,y,z,t> where t is the float-position along
> the spline's length. MySpline[Value].xyz would return a 3d version of the
> control point. Transformations would apply to all values on the 'spline
> array' except for the t values unless specifically called for by use of dot
> operators.
>
> Charles
>
> PS (Woohoo! I was able to log on today from home with my high latency
> connection!)
Well, I consider all these features as being 'low_level' and 'detailed
design'. If we say that the new SDL will be more or less object-oriented,
we involve most of those features you and others have mentionned.
Object-orientedness can be implemented in quite a heavy way (eg Java, Ada),
or more 'light'. But in any case we have the dot operator, structures,
modules + visibility rules, attributes & methods etc .. etc ...
My opinion is that we have to make higher-level and main orientations
choices now before anything else. Some people are capable of envisionning
high levels of a system, some can extract general features from a messy
list of collected requirements of all kinds (there are structured methods
for that), etc ...
It is important to me that we have to focus on 'WHAT' (and why) rather than
'HOW'.
And my feeling is that the new SDL should be object-oriented yet
user-friendly and inherit POV syntax for what POV is VERY efficient for:
describing objects and textures.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter <jrc### [at] msncom> wrote:
> Since we are undertaking the conversation. I would enjoy having you
> sketch this out a little more. I hit a bump, conceptually, when I see
> the term 'shader language'. I am not really sure what it means in
> relation to the texturing that POV uses. You are usually pretty good at
> sorting out these kind of semantic/conceptual tangles for us that are
> less technical. For instance I thought that 'shader language' went
> along with 'scanline rendering'
Shaders are not inherent to scanline-renderers, even though the vast
majority of shaders are used in scanline-renderers (most notably modern
3D acceleration cards support shaders).
The idea of shaders is that instead of having a limited set of hard-coded
algorithms for calculating surface texturing (which was the case with older
renderers, older 3D acceleration cards, and closest to home, is the case
with POV-Ray), the engine offers an efficient language which can be used to
add new algorithms used to determine the color of the surface.
Let's take, for example, the 'finish' block of POV-Ray. While there are
quite many parameters to fine-tune, it's still a fixed amount of possible
parameters. As an example, fresnel reflection is available only because
it has been added to the core code. However, if you would want to test
with some other type of reflection algorithm there just isn't an easy
way (the only way is to modify the source code and recompile the program).
A shader language allows you to create new types of algorithms to calculate
reflection, or almost anything else related to the surface coloring.
There are many nice tricks which can be relatively easily achieved with
shaders (which would otherwise require specific hard-coded support in the
core code) such as furry texturing, subsurface scattering, etc.
Of course it's not like this feature was mandatory for povray, but it
would be nice to have.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jim Charter <jrc### [at] msncom> wrote:
>> I hit a bump, conceptually, when I see the term 'shader language'.
>
> The idea of shaders is that instead of having a limited set of
> hard-coded algorithms for calculating surface texturing <snip>
> the engine offers an efficient language which can be used to
> add new algorithms used to determine the color of the surface.
Just to add a bit to what Warp has said.
A shader language would allow a user of SDL access to more of what
POV-Ray knows abut a surface, light_source, etc.
An example is the calculation of a specular highlight which requires
knowledge of the angle of incidence of a light_source to a surface.
Bringing that information to the user on a ray by ray basis would allow
for things like:
#if AOI > SomeNumber color_it_this_way #else color_it_another_way
or
pigment { AOI * Something + SomethingElse color_map { ...
A possibly more exciting example to a traditional media artist like
yourself: You'll be familiar with the concept of shading and tinting
paint. POV-Ray (effectively) shades colors as they darken, with access
to the illumination of a ray intersection, you could instead tint colors
as they lighten.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp and Shay, Thanks and thanks.
I think it is always good to expose internal functionality to the
artists, where possible. I will always remember the creative spurt that
accompanied the introduction of the trace() and eval_pigment() functions
which I saw in just that way, as exposing internals to the user.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
FYI I will this weekend attempt to get a wiki set up on povray.org.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
>
> Let's take, for example, the 'finish' block of POV-Ray. While there are
> quite many parameters to fine-tune, it's still a fixed amount of possible
> parameters. As an example, fresnel reflection is available only because
> it has been added to the core code. However, if you would want to test
> with some other type of reflection algorithm there just isn't an easy
> way (the only way is to modify the source code and recompile the program).
We could imagine this :
- a shading language with it's own syntax (it have to be very
"programmatic"), allowing any algorithm one can imagine
- while, in POV-Ray SDL, existing texture/pigment/normal/finish features
are kept mostly as they are currently, but actually (and transparently
to user) uses stuff defined in the new shading language.
Each existing pattern, reflection algoritm,... has to be transcribed
in shading language, which would form a huge base of sample code to
start writing new shaders.
Users can limit themselves to existing stuff without re-learning
anything. Those who'd like to get their hands dirty can do it with
a smooth learning curve.
this would also put all texture-related algorithms out of POV-Ray's main
code, and allow people who aren't high-end programmers to contribute
to an important part of POV-Ray (thus less time spent on it by better
programmers in the re-write process).
(light sources and cameras should also become shaders, ideally, BTW)
note : some years ago, someone made a "POV-Man", which was POV-Ray
with the ability to use RenderMan shaders. It would be interesting
to find it back and have a look.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
>
> Just to add a bit to what Warp has said.
>
> A shader language would allow a user of SDL access to more of what
> POV-Ray knows abut a surface, light_source, etc.
>
> -Shay
As an illustration of that, we can 'pigment' and 'normal' our textures with
user-defined functions. Its is highly embryonic, but it already opens
perspectives for those who can imagine functions. I guess some of you have
obtained nice results.
And in addition, POV's principle of having user-modifiable patterns
(including functions) with color_maps or pigment_maps and many
possibilities for 'finish' is so much flexible that all the stuff produced
so far with POV uses it.
This makes me say that, in a way, POV has already some kind of 'shader
language'.
BUT: we can (it's time to) go much further. A true shader language might
open entire worlds for artists and for those who want to ilmitate nature.
Ideas welcome. Can somebody remind us Renderman's approach of shaders? We
can get inspired by existing solutions.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> - while, in POV-Ray SDL, existing texture/pigment/normal/finish features
> are kept mostly as they are currently, but actually (and transparently
> to user) uses stuff defined in the new shading language.
That assumes that they will be as fast as they are currently. If changing
them to use the shading language would make them slower then it would be
a setback.
The purpose of a shading language is to open new options, not to make
existing options worse (ie. slower).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In general I think that the object definition syntax of the
current SDL should be preserved. I also agree that the
addition of additional features would be good, though
command-set bloat should be avoided. My wish list includes...
1) An optional "environment {}" command section where
the command line options for a scene can be placed within
the scene file (like the COBOL environment section).
One objection I've read on this is that letting the
environment (image size, animation options, etc.) be set
from inside the scene file breaks compatibility with the old
system, but it would be easy to get around that by just
adding a "default" setting to quick-rez, if it's rendered with
default it reads environment {} otherwise it ignores it.
2) Better medias. IMO fixing this will eventually lead to
re-defining the syntax for medias, and possibly the need
to resort to scan-line like routines, particularly for things
like sub-surface light scattering. The upside here is the
possibility of describing the way a media should look,
instead of tweaking commands to the routines that are
supposed to get the look, but often don't. This matches
the original philosophy of SDL, SDL is a description of
a scene, not a description of the algorithms needed to
render a scene.
3) Binary reading from files.
4) Post processing of images. This could fall under something
like a post_process{} section. One thing that might be nice
here would be the ability to directly produce animation files in a
couple of formats.
5) Allow the linking of external libraries, so that POV can
access custom programming routines from various languages.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> - while, in POV-Ray SDL, existing texture/pigment/normal/finish features
>> are kept mostly as they are currently, but actually (and transparently
>> to user) uses stuff defined in the new shading language.
>
> That assumes that they will be as fast as they are currently. If changing
> them to use the shading language would make them slower then it would be
> a setback.
>
> The purpose of a shading language is to open new options, not to make
> existing options worse (ie. slower).
If the shaders are compiled on the fly before rendering (which is, IMMSMW,
what POV-Man did), could they really be slower than hard-coded ones ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> If the shaders are compiled on the fly before rendering (which is, IMMSMW,
> what POV-Man did), could they really be slower than hard-coded ones ?
It assumes that the shaders can be compiled and that the compiler will
be able to optimize them in the same way is the C++ compiler optimizes the
current algorithms written in C++.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
> end to any SDL was necessary for speed. If this was exposed and formally
> documented then, firstly, more or less any language could be used with it
> (assuming someone wants to write the translator), and secondly, portability
> is at least vaguely possible by providing a reverse-compiler that outputs
> some form of 'standard' SDL (whatever we end up calling 'standard' is up to
> question of course).
Maybe we need something more POV-Ray specific, but I thought I should bring
this up anyway... Have you heard of the Parrot bytecode[1]?
Languages already supported (even if they are incomplete and experimental):
Perl 6, APL, BASIC, Befunge, Brainfuck, Cola, Forth, Jako, Lisp, m4,
Miniperl, Parakeet, OpenComal, PHP, Plot, Pheme, Punie, Python, Ruby,
Scheme, Span, Tcl (aka partcl), URM, YAL, and Zork Z-code.
[1] http://en.wikipedia.org/wiki/Parrot_virtual_machine
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> C coding with a basic understanding of C++ would probably be sufficient for
> many of the tasks in re-writing the code that has to be replaced. Recall that
> all the POV code was originally c, and the fundamental core of the algorithms
> and objects are still readable by a C programmer.
Please don't let POV-Ray be written in "C plus classes". C++ is so much more
than that! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Thorsten Froehlich wrote:
> > The solution to the parse vs render time limits would be to make all
> > features of a scene object replaceable by the user from within the language
> > - i.e. even replace the intersection algorithm or the transformation
> > computations. That would also put POV on-par with Renderman.
>
> That would be rather neat.
I would like to have *everything* easily changed by tweaking the sourcecode.
Say, make a *totally different* renderer like WinOSI [1] while keeping all
the objects and textures that POV-Ray gives. (WinOSI has some great
lighting but it doesn't even have CSG!).
[1] http://www.winosi.onlinehome.de/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> andrel wrote:
> > Can someone set something up somewhere?
>
> Can someone recommend specific Wiki software?
>
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.
>
> Anyone have any experience with this?
Somebody managed to "link" MediaWiki with BOINC accounts, and even with some
features like if somebody gets banned from the BOINC forum, he can't edit
the wiki either. I think there was also some experiments about making page
editing permission dependent on how much CPU time you had contributed to
the project!
http://pirates.spy-hill.net/glossary/
I can give you the admin's email if you want to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
>> end to any SDL was necessary for speed. If this was exposed and formally
>> documented then, firstly, more or less any language could be used with it
>> (assuming someone wants to write the translator), and secondly, portability
>> is at least vaguely possible by providing a reverse-compiler that outputs
>> some form of 'standard' SDL (whatever we end up calling 'standard' is up to
>> question of course).
>
> Maybe we need something more POV-Ray specific, but I thought I should bring
> this up anyway... Have you heard of the Parrot bytecode[1]?
Check out llvm.org
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Attwood wrote:
> 1) An optional "environment {}" command section where
> the command line options for a scene can be placed within
> the scene file (like the COBOL environment section).
> One objection I've read on this is that letting the
> environment (image size, animation options, etc.) be set
> from inside the scene file breaks compatibility with the old
> system, but it would be easy to get around that by just
The real objection seems to be that this would make it harder to
separate the front end and back end of the program, and make it harder
to do things like distributed renders.
> 3) Binary reading from files.
Hmm, could be useful for parsing oddball 3D formats in POV code.
At the very least, it would be nice to have more flexibility in reading
ASCII files. I would like to be able to parse files that are not
comma-delimited. :-) Any thoughts on supporting a scanf-style syntax?
> 4) Post processing of images. This could fall under something
> like a post_process{} section. One thing that might be nice
> here would be the ability to directly produce animation files in a
> couple of formats.
That would be cool.
> 5) Allow the linking of external libraries, so that POV can
> access custom programming routines from various languages.
I'm of two minds on this.
This would be *very* useful. If there's something that you can't do in
SDL, you can add it. :-)
On the other hand, it becomes possible to write malicious POV files. How
would you like to download a scene file and have it erase all your files
when you try to render it? Not good.
That's a tough one, because it's not a technological problem so much as
a social one. :-(
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when someone shows you a
photograph of their new rough-slate kitchen floor and you say "nice
normals".
-- Tom Melly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG/a1bcCmTzQ++ZncRAlfgAJ46lgwdHuaBtvWR07zC8IaepfFvWgCgjngm
PmiieCkTgNo9vMhHPctVQOA=
=mF0i
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 24 Sep 2007 17:47:45 +1000, Chris Cason wrote:
> andrel wrote:
>> Can someone set something up somewhere?
>
> Can someone recommend specific Wiki software?
>
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.
Hey, Chris - willing to help out here, but I do need to understand a bit
more about the user registration system. I'm sure there's a way to make
it work with Mediawiki.
I can be reached at hendersj at gmail (just realised I post with a fake e-
mail address here, so you may have wanted to contact me but were unable
to)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>
>>C coding with a basic understanding of C++ would probably be sufficient for
>>many of the tasks in re-writing the code that has to be replaced. Recall that
>>all the POV code was originally c, and the fundamental core of the algorithms
>>and objects are still readable by a C programmer.
>
>
> Please don't let POV-Ray be written in "C plus classes". C++ is so much more
> than that! :)
Well, since you were the first one to say it...
Yeah, C++ has more features than the classes, but the classes provide a
great deal of the advantage that C++ has over C, mainly because of the
way that classes lead to better organization of code.
The polymorphism helps a lot, too, but on a project as large as POV-Ray,
the ability to organize code in a consistent way will bring benefits
that will make the benefit from other features easy to overlook.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle escribió:
> Nicolas Alvarez wrote:
>>
>>
>> Please don't let POV-Ray be written in "C plus classes". C++ is so
>> much more
>> than that! :)
>
> Well, since you were the first one to say it...
>
> Yeah, C++ has more features than the classes, but the classes provide a
> great deal of the advantage that C++ has over C, mainly because of the
> way that classes lead to better organization of code.
>
> The polymorphism helps a lot, too, but on a project as large as POV-Ray,
> the ability to organize code in a consistent way will bring benefits
> that will make the benefit from other features easy to overlook.
>
> Regards,
> John
Of course classes are one big advantage over plain C. But (following
your example) polymorphism helps a *big* lot to something like POV-Ray.
You have an abstract Object class (in C++ that would mean it has pure
virtual methods), and classes that extend it like Sphere, Cylinder,
Isosurface, and probably CSG objects too (I don't know how CSG code is
organized currently). You can also have a Camera class with the
different projections inheriting from it, instead of the *big* switch
block that is used now. Classes give "the ability to organize code in a
consistent way". Polymorphism gives the ability to use those classes in
a consistent (or should I say *identical*?) way.
Objects all have the same basic interface after all. Intersect ray,
is-point-inside-object, etc. So do camera projections, they basically
just have to convert a 2D point (pixel in final image) into a starting
point and a direction.
I can imagine it would be a lot easier to add a new object / camera
projection / pattern on an unofficial POV if it's all nice OOP. For
example, the parser could be split that way too (ObjectParser where
SphereParser etc extend from). Not much more than write two classes and
add new keywords to the lexer and you're done...
What about exceptions? Probably not very useful for the renderer, but I
think they could help for the parser, or the frontend-backend separation
"thing".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy nous apporta ses lumieres en ce 2007/09/28 21:41:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tim Attwood wrote:
>> 1) An optional "environment {}" command section where
>> the command line options for a scene can be placed within
>> the scene file (like the COBOL environment section).
>> One objection I've read on this is that letting the
>> environment (image size, animation options, etc.) be set
>> from inside the scene file breaks compatibility with the old
>> system, but it would be easy to get around that by just
>
> The real objection seems to be that this would make it harder to
> separate the front end and back end of the program, and make it harder
> to do things like distributed renders.
>
>> 3) Binary reading from files.
>
> Hmm, could be useful for parsing oddball 3D formats in POV code.
>
> At the very least, it would be nice to have more flexibility in reading
> ASCII files. I would like to be able to parse files that are not
> comma-delimited. :-) Any thoughts on supporting a scanf-style syntax?
>
>> 4) Post processing of images. This could fall under something
>> like a post_process{} section. One thing that might be nice
>> here would be the ability to directly produce animation files in a
>> couple of formats.
>
> That would be cool.
>
>> 5) Allow the linking of external libraries, so that POV can
>> access custom programming routines from various languages.
>
> I'm of two minds on this.
>
> This would be *very* useful. If there's something that you can't do in
> SDL, you can add it. :-)
>
> On the other hand, it becomes possible to write malicious POV files. How
> would you like to download a scene file and have it erase all your files
> when you try to render it? Not good.
>
> That's a tough one, because it's not a technological problem so much as
> a social one. :-(
>
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
>
> You know you've been raytracing too long when someone shows you a
> photograph of their new rough-slate kitchen floor and you say "nice
> normals".
> -- Tom Melly
>
That last point can be elliminated by strictly enforcing I/O restrictions for
ANY external addon. An external module/addon/plugin could be strictly forbiden
to erase any file, modify any file that don't share the same base name as the
current scene, create any file outside the default write permition.
Going further, strictly forbide any I/O operation to any external library.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when your personal correspondence to
friends starts out with #Dear Linda =
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alain wrote:
> That last point can be elliminated by strictly enforcing I/O
> restrictions for ANY external addon. An external module/addon/plugin
> could be strictly forbiden to erase any file, modify any file that don't
> share the same base name as the current scene, create any file outside
> the default write permition.
> Going further, strictly forbide any I/O operation to any external library.
That's just it: Once you launch an external process, you have no control
over it. There's no way whatsoever to enforce I/O restrictions.
I suppose that under Unix/Linux you could run it under a chroot, but I'm
not aware that Windows supports anything like that. The ideal solution
would be an OpenBSD jail, but most users don't run OpenBSD...
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you can no longer tell the
difference between the top raytracing book and the "Raytracing for
Dummies" book. To you, they're both hopelessly uninformed.
-- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG/oSTcCmTzQ++ZncRAgsOAJ9Ysqry0z2mOExNgFPd6z0rwToJuQCgn4pH
+Oo9saOfPo1DkCZfQFIJOxo=
=Bo7d
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy nous apporta ses lumieres en ce 2007/09/29 13:00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alain wrote:
>> That last point can be elliminated by strictly enforcing I/O
>> restrictions for ANY external addon. An external module/addon/plugin
>> could be strictly forbiden to erase any file, modify any file that don't
>> share the same base name as the current scene, create any file outside
>> the default write permition.
>> Going further, strictly forbide any I/O operation to any external library.
>
> That's just it: Once you launch an external process, you have no control
> over it. There's no way whatsoever to enforce I/O restrictions.
>
> I suppose that under Unix/Linux you could run it under a chroot, but I'm
> not aware that Windows supports anything like that. The ideal solution
> would be an OpenBSD jail, but most users don't run OpenBSD...
>
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
>
> You know you've been raytracing too long when you can no longer tell the
> difference between the top raytracing book and the "Raytracing for
> Dummies" book. To you, they're both hopelessly uninformed.
> -- Taps a.k.a. Tapio Vocadlo
There is a way, it's called "sandboxing". The process runs in a limited, closed,
virtual machine and only have access to what YOU want it to see. That way, the
process may never even "know" that there is a disk or anything else. It can't
launch another programm, because it can't locate any programm but those you
explicitely permit it to see. And those other programms can only be launched in
that same sandbox. Upon termination, the calling application retreive the
result, and terminate the virtual machine and anything in it, now and
unconditionaly.
This can be done indepently of the OS you use and the CPU used.
--
Alain
-------------------------------------------------
The strongest reason for the people to retain the right to keep and bear
arms is, as a last resort, to protect themselves against tyranny in
government.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy wrote:
>> 5) Allow the linking of external libraries, so that POV can
>> access custom programming routines from various languages.
>
> I'm of two minds on this.
>
> This would be *very* useful. If there's something that you can't do in
> SDL, you can add it. :-)
>
> On the other hand, it becomes possible to write malicious POV files. How
> would you like to download a scene file and have it erase all your files
> when you try to render it? Not good.
>
> That's a tough one, because it's not a technological problem so much as
> a social one. :-(
It could also make the POV community diverge in groups with different sets
of libraries. E.g. because some libraries are only available for a
subset of OSes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Before adding it to my temporary (until the wiki comes on-line)
new-POV-page (http://members.chello.nl/a.c.linnenbank/newsdlforpov.html)
I though it would be better to discuss here.
Just an observation:
The syntax for our objects is what makes POV different from most other
languages its syntax is something like:
object{parameters modifiers)
e.g.
sphere{ <x,y,z>,r
pigment{rgb <r,g,b>}
rotate <rx,ry,rz>
translate <tx,ty,tz>
}
Note that there a re three totally different arguments here.
- the assignment to pigment could be though of as accessing a class
element, more conventionally denoted as sphere.pigment=...
That might also be the standard (preprocessor ;) ) translation if POV4
will be based on another language.
There is also the concept that you can have a pigment statement where
ever you need a texture.
- <x,y,z> and r are unnamed but in a definition of sphere they could be
defined as (introducing a new object definition syntax [1])
object: sphere(vec3D: location, scalar: radius)
so if you know this definition you could access sphere.location and
sphere.radius
- the family of modifiers that change the appearance of the object
(rotate, translate, scale and such). The members of this family interact
so the natural interpretation is that these are member functions.
[1] do we need a object definition syntax in POV4? I think we do, how
else could we define new object types? This may also be the point to
mention that the current set of primitive objects is far from
consistent. We have sphere{<Center>, Radius} while we also have
box{<Corner_1>,<Corner_2>}, why don't we have cube{<Center>, size} or
cube{<Center>, <size>}? And why do we have to translate the
superellipsoid manually with a translate?
PS: what exactly was my point? I am sure I have seen it less than half
an hour ago.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alain wrote:
> There is a way, it's called "sandboxing". The process runs in a limited,
> closed, virtual machine and only have access to what YOU want it to see.
So, you propose that every time POV code loads an external program, you
launch a full-scale virtual machine? Are we going to license something
from VMware? Are you going to ask people to buy extra licenses from
Microsoft for the copies of the operating system running inside the VM?
(Jeez, I'm starting to sound like Warp.)
Sandboxing is great for your language's own scripts/bytecode, but is
less than helpful for _external_ libraries and arbitrary programs, which
is what we were talking about.
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you have gone full circle
and find your self writing a scene that contains only a shiny sphere
hovering over a green and yellow checkered plane.
-- Ken Tyler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHACUgcCmTzQ++ZncRAhqzAKCumUBVkzdhWSIUV8/G8eshSDgPtwCgskNO
BG4sB+d9gHRekR6ZpSLULsM=
=hbRb
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
andrel wrote:
> It could also make the POV community diverge in groups with different sets
> of libraries. E.g. because some libraries are only available for a
> subset of OSes.
If that were the only problem, the extra flexibility would be well worth it.
This is one of those things that I would only expect 10% of the userbase
to even touch--if lots of people wind up needing it, it's because we
screwed something up.
Besides, we already have that showing up with people using modelers and
such. Remember that Pose-ray is Windows-only?
I'd say make as much as you can work inside of Pov (hence the argument
for a much expanded SDL that does things that people now use external
programs for), and then get out of the way of everyone that we can't
directly support.
Unless of course you want to include every obscure scientific
visualization library into Pov. ;-)
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you spent the whole of
Titanic wishing the actors would get out of the way.
-- Dylan Beattie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHACaBcCmTzQ++ZncRAoRHAJ9thPyTTKsPvYOMIWxDHEn/h8yMMwCbBog2
tJM2kV5P2tat0y4KqFs+QzY=
=Tek1
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicolas Alvarez wrote:
> Maybe we need something more POV-Ray specific, but I thought I should bring
> this up anyway... Have you heard of the Parrot bytecode[1]?
I haven't, but it looks very interesting.
- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
You know you've been raytracing too long when you know the teapot bezier
patches by heart.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHAClNcCmTzQ++ZncRAjeeAJ4giIt/pRxVNSg5CWzY65A1RPf3AACdEOJf
reBNYooeE7hrsFp1zbAHJyE=
=mI9h
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 30 Sep 2007 15:43:13 -0700, William Tracy wrote:
> If that were the only problem, the extra flexibility would be well worth
> it.
Only so far as the features one wants are in the OS that one is using.
If you've used any OS other than Windows in the last 10 years, you've
come to expect that full functionality may not be available in the OS of
your choice.
Purposefully designing a program so that this can happen is a bad idea.
If you pop over to the povray.unix group, you can see that some are
already unhappy with the fact that POVRay on Windows has a "nice GUI"
<spit - I prefer CLI myself>, but on *nix platforms, all you get is an
"ugly CLI interface".
Now extend that to features in the language itself - that's a recipe for
chaos, because the POVRay you use on *nix may not necessarily have the
same functionality as the Windows version, and your scene files won't
actually render because of missing functionality. You end up with an SDL
that is *not* portable. Nonportability is BAD.
> Besides, we already have that showing up with people using modelers and
> such. Remember that Pose-ray is Windows-only?
That's a bit different than limiting the featureset of POVRay itself for
users of some OSes.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy <wtr### [at] calpolyedu> wrote:
> Nicolas Alvarez wrote:
> Have you heard of the Parrot bytecode[1]?
>
> I haven't, but it looks very interesting.
until you realize it's something, like Perl6 itself, that has been in the
works for about 6 years, without ever managing to get out of beta status.
In the hiatus, the python community came up with an innovative VM system
called PyPy and ruby increased its presence immensely. And Lua too got a
lot of critical acclaim...
I was thinking... the next Povray supposedly is going to be GPL. Would you
guys find it feasible to ship it together with GCC? My point is:
JIT-compilation is still a relatively new area and there aren't sufficient
open-source implementations out there. But traditional ahead-of-time
compilation is easily achieved. If it was possible for a povray SDL script
to be compiled before running, performance wouldn't be a problem any more.
then, I could even suggest getting a Scheme implementation like chicken to
be a possible SDL frontend... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> If the shaders are compiled on the fly before rendering (which is, IMMSMW,
>> what POV-Man did), could they really be slower than hard-coded ones ?
>
> It assumes that the shaders can be compiled and that the compiler will
> be able to optimize them in the same way is the C++ compiler optimizes the
> current algorithms written in C++.
The most fundamental (and time-consuming) algorithms could be hard-coded
(ior, fractal noise, turbulence, whatever...) to gain the most speed.
And if the shader language is, in fact, an existing language, like C or Ruby,
or any smart choice, making use of POV-Ray-specific classes, efficient
compilation shouldn't be a problem (I think).
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
