Le 03.10.2007 20:35, Shay nous fit lire :
> Subdivision? Of what? Who creates
> mesh models without a mouse (except me)?
> 

Well, as you ask, me! I transform some solid object in mesh, then
deform them in pov. (personnal edition, of course...)

> This will all sound a lot better after someone has taken care of the
> many things that POV users cannot do (rendering algorithms). After that,
> what POV users cannot *conveniently* do might seem a lot more important.

I'm afraid of a chicken-egg issue in this sterile discussion about SDL.
A full clean-up of the data model would be needed first (far away
from the SDL, at the lowest memory level). Once the future data
model is stable (and beautiful ?), we could look at any rendering
algorithm to see if it fit the actual data or require an extension
(or a bigger evolution). That's something that cannot be done "on
the wind", you need a practical algorithm. Documenting the
data-model could save the trouble for the future generation.
Then, with a reliable data-model, you can have any loony designs its
own SDL to fill that data (or explore it, too). You can even
anticipate a serialisation of the actual data, for easier
saving/loading (including distributed rendering). And again, the
serialisation can be done in whatever loony's designed syntax (XML,
ASN.1 (BER or PER or whatever), bytecode, ...) they want it.

The purpose of parsing is to generate the data for the rendering
engine, everything else are just commodities for the users.

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

St. <dot### [at] dotcom> wrote:
> As it happens, from a non-programmers point of 
> view, I think this thread has been a frenzy of what everyone *wants*

  No, it's not about what everyone wants, it's about what POV-Ray needs.

  POV-Ray needs to improve, else it will slowly fade into oblivion.
The SMP support in POV-Ray 3.7 bought it time, which is really great,
but I'm afraid that will not be enough in the long run. The SMP support
is a huge card for POV-Ray, but it just needs more if it wants to survive
another 15 years.

  One thing which POV-Ray needs is more rendering features which would
bring it back in par with other renderers.

  While many such rendering features must be added to the core code
because there's no other option, there are, however, a whole lot of
features which can and should be implemented by scripting. These can
often be implemented as surface shaders and such.
  Implementing them with scripting has tons of advantages. The features
become more flexible, easily modifiable (without having to recompile
the entire program) and extensible. POV-Ray should move from a rigid
monolithic architecture to a more flexible architecture where features
can be added without touching the core code. Only features which simply
cannot be implemented with scripting, for example because of efficiency
reasons, should be implemented in the core code.
  There are also many other features which would benefit from scripting
support, such as importing and exporting of file formats (how many times
has a converter from POV-Ray to other formats been requested?)

  Also, POV-Ray cannot simply drop its scripting language. This is simply
because the scripting language is one of the major features, which
differentiates it from many other similar renderers. I fear that if
POV-Ray was a pure renderer, with no scripting support, it would have
been forgotten long time ago.

-- 
                                                          - Warp

Post a reply to this message

> POV-Ray should move from a rigid
> monolithic architecture to a more flexible architecture where features
> can be added without touching the core code. Only features which simply
> cannot be implemented with scripting, for example because of efficiency
> reasons, should be implemented in the core code.

In my opinion, it's currently in a state where it is a rigid monolithic 
architecture where adding features even by touching the core code is 
very hard. It should start by being flexible there. Then make it scripted.

Adding a pattern, an object, a camera projection, or a different 
lighting algorithm shouldn't take months of trying to figure out the 
existing code.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> In my opinion, it's currently in a state where it is a rigid monolithic 
> architecture where adding features even by touching the core code is 
> very hard. It should start by being flexible there. Then make it scripted.

  Making it scripted is exactly the way to move out from being monolithic.
You can't separate these two things.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   No, it's not about what everyone wants, it's about what
> POV-Ray needs.

The Big Picture:

What POV-Ray needs to survive for another 15 years is for a decent 
number of people to post high-quality work on places like CGTalk. For 
that to happen, the program needs rendering capabilities and users.

Features like shaders (with necessary procedural capabilities), improved 
motion-blur, improved AA, nurbs, an accessible scripting language, and 
modeller integration will draw more users and allow those and current 
users to create more impressive works. Adding clutter (and almost 
certainly new bugs) to the interface for the purpose of overlapping the 
capabilities of existing, non-renderer tools will not.

The low-level language creating the mid-level language creating the 
high-level language (resulting in "#include ... function-call ( ...") is 
a programmer's fantasy somewhat like "you can use c++ as a high-level 
language if you have the right libraries." Introduce lower-level 
programming tools into the SDL for the purpose of coding 
mesh-manipulation or text-reading libraries, and these tools will creep 
into the high-level (common user) code. The effect of this is that 
examples of POV SDL become nearly useless to those not familiar with a 
very large portion of the SDL.

> Also, POV-Ray cannot simply drop its scripting language. This is
> simply because the scripting language is one of the major features,
> which differentiates it from many other similar renderers.

Agreed, but this scripting support must be accessible to draw and keep 
users.

  -Shay

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:47040a89@news.povray.org...
> St. <dot### [at] dotcom> wrote:
>> As it happens, from a non-programmers point of
>> view, I think this thread has been a frenzy of what everyone *wants*
>
>  No, it's not about what everyone wants, it's about what POV-Ray needs.

    Well, yes, that's true.


>
>  POV-Ray needs to improve, else it will slowly fade into oblivion.

     I'm with you, I understand this.


>  There are also many other features which would benefit from scripting
> support, such as importing and exporting of file formats (how many times
> has a converter from POV-Ray to other formats been requested?)

      True, many, many, times.


>
>  Also, POV-Ray cannot simply drop its scripting language. This is simply
> because the scripting language is one of the major features, which
> differentiates it from many other similar renderers. I fear that if
> POV-Ray was a pure renderer, with no scripting support, it would have
> been forgotten long time ago.

  Couldn't we just call Moray 'Pov-Ray', and work with that?

    ~Steve~






>
> -- 
>                                                          - Warp

Post a reply to this message

> Agreed, but this scripting support must be accessible to draw and keep 
> users.

I second that.  Simple things (and moderately complex things) that we do
now with POV 3.6 must remain simple to do in any future development.

However, provided the above, being able to do more complex things, or
doing it with more flexibility, on top of that, is a necessary evolution.

Fabien.

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> Adding clutter (and almost 
> certainly new bugs) to the interface for the purpose of overlapping the 
> capabilities of existing, non-renderer tools will not.

  For some reason you have this obsessive fixation about "if it can be
done with third-party tools, it should not be added to POV-Ray".

  Well, you know what? 3D images can be rendered with third-party programs.
Thus, by your logic, rendering support is not necessary in POV-Ray because
you can do it with other programs.

  So what if you can calculate subdivision of meshes with third-party tools.
Can you guess how many of these tools I have in my computer? Moreover, can
you guess how many of these tools are not available at all for my OS?

  Besides, even if I had a subdivision-capable program available for my OS,
it would still be clumsy to use. I would have to create or convert the mesh
to a format supported by that program, then I would have to perform the
subdivision, then I would have to export or convert the result to a POV-Ray
mesh, and then I would have to write the SDL file to read that mesh.
  Naturally this becomes more complicated if the original mesh was created
with POV-Ray itself (for example I have an include file which creates a
mesh in the shape of a surface of revolution, given the outline spline).

  It would be really, really handy if I could perform the subdivision in
POV-Ray itself. No conversions, no saving, no temporary files, no nothing.
Just one command and there you are: I have the subdivided mesh.

  Why you think enhancing POV-Ray in a way that allows creating this kind
of functionality is a bad thing goes beyond my comprehension.

-- 
                                                          - Warp

Post a reply to this message

St. <dot### [at] dotcom> wrote:
>   Couldn't we just call Moray 'Pov-Ray', and work with that?

  No, because Moray is windows-only.

-- 
                                                          - Warp

Post a reply to this message

> St. <dot### [at] dotcom> wrote:
>>   Couldn't we just call Moray 'Pov-Ray', and work with that?
> 
>   No, because Moray is windows-only.

I think he's joking...

Fabien.

Post a reply to this message