 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kyle <hob### [at] gate net> wrote:
> I'm sure this has already been requested at some point, but I'd like to have the
ability to define image parameters from within the scene file. These parameters must
currently be defined at the
> command line or within an ini file.
Not gonna happen because it breaks the boundary between the frontend and
the backend, and this cannot be broken while still preserving the abstraction
level necessary for distributed rendering and such.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
page updated with your and warp's comments. Hmm, I think I need some
version control system here. Perhaps I should also leave my old habit of
writing plain HTML in a text editor. Anyone some (meta) suggestions?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> Perhaps I should also leave my old habit of
> writing plain HTML in a text editor.
If you are writing HTML, then please use the available features HTML
offers, such as <pre>, <code>, etc, to make the page clearer and easier
to read.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Perhaps I should also leave my old habit of
>> writing plain HTML in a text editor.
>
> If you are writing HTML, then please use the available features HTML
> offers, such as <pre>, <code>, etc, to make the page clearer and easier
> to read.
>
Sorry, I'll see what I can do. As some kind of excuse: I have been
writing simple HTML since the first Mosaic came out and I designed the
first version of a website for a biomedical engineering federation (the
IFMBE.org), and I did not need code snippets for that. I never improved
my knowledge of html since. ;) So no style sheets for me. BTW I also
made the changes bold, does that improve the reading or does it hamper it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 ;-)
--
Alain
-------------------------------------------------
"Having a smoking area in a restaurant is like having a peeing area in a pool."
--Thomas Pfeffer, American Heart Association
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] cccc> 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
|
|
| |
| |
|
|
|
|
| |
|
|
