 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
