Warp wrote:
> Shay <Sha### [at] cccc> wrote:
>> C) Invent and code a new programming language and then code the 
>> algorithm in that language.
> 
> Right, because all that is necessary for every single algorithm which
> will be ever made for POV-Ray.
> 

Not quite. I suppose one set of commands would take care of a handful of 
converters. The mesh-handling stuff? Well there's decimation for 
marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates 
mesh models without a mouse (except me)?

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.

  -Shay

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> Not quite. I suppose one set of commands would take care of a handful of 
> converters. The mesh-handling stuff? Well there's decimation for 
> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates 
> mesh models without a mouse (except me)?

  I really don't understand your attitude. You are mocking the few
examples given (and even quite illogically at that) and you refuse to
see the big picture behind those examples.

-- 
                                                          - Warp

Post a reply to this message

In article <470313c2@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > In article <47024d79$1@news.povray.org>, 
> > nic### [at] gmailisthebestcom says...
> >> Umm... Isn't that how things work on *any* loosely-typed language?
> >>
> >> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3
)];
> >>
> >> A valid Javascript array containing a number, another array, a string,
 a 
> >> regular expression, and a Sphere (provided that the Sphere object was
 
> >> defined).
> >>
> > Well, all I know is that it wasn't, for what ever reason, possible with
 
> > the client. That *may* be due to the fact that Java is *not* normally
 
> > that loosely typed, or that some serious problem existed in ActiveScrip
t 
> > which seriously fracked it (since it relies a lot of that for every 
> > language except Lua. Though, mind you, half the ActiveScript languages
 
> > seem to not follow spec anyway and suffer from bloody silly 
> > inconsistencies even in how you instance them, never mind get them to d
o 
> > anything after they are linked.)
> > 
> 
> You're mixing up Java and Javascript (they have nothing to do, name 
> similarity is apparently because of marketing reasons). Java is 
> strongly-typed, Javascript is loosely-typed. Java is compiled into 
> bytecode, Javascript is interpreted. Java has classes, Javascript has 
> prototype-based OOP instead.
> 
I realize there are differences between them, didn't know that was one 
of them though. I still don't like the syntax that well. My point was 
though that you get the same issues trying to use something like Python. 
It didn't link the same way, even though it should have, and worse, 
there actually seems to be some sort of insane memory leak in it, 
triggered when you drop in some temp code to run, then try to remove it 
again. We are not sure if its garbage collection not handling the 
deleted code correctly or what, but its frustrating.

Oh, and using Java may not be useful precisely *because* it relies on 
compiled Bytecode. Why? Because I am not sure how well it can handle 
shifting code in/out on the fly, and while I am not sure how/if that 
would be useful in POVRay, since it kind of assumes you are going to 
render one frame, then exit, it is a nice things to have some times. 
Like say you have a flag to turn off a certain feature, while testing 
colors, because it slows things down. So, you figure, "Ok, color is 
good, so lets just type in "myflag = 1", so the next frame will render 
"with" the feature turned on, so I can see it that is working too, 
without having to restart the entire render." Sure, its not the sort of 
thing you "expect" to be doing in a program like this, but it can be 
useful some times to have immediate execution of a comment "into" the 
code that is already running, in some cases. You can't do that with 
compiled code.

Now, whether there is a legitimate reason to allow such a thing in 
POVRay is another question entirely, as well as how that would effect 
speed. But it is something that might be considered. Its also used in 
the client I use to do things like reacting to some event, then 
inserting code to do some specific task "at that event". Probably not 
useful or necessary for POVRay, since coding that in directly, then re-
running the script, is probable just as easy, but again, its something 
that could be done real time, even as processing is being done, in the 
client I use, while a compiled language simply wouldn't support it. 
Useful for something like POVRay or completely useless? Not sure myself. 
I am sure I could think of uses for it "if" I had the option, but 
thinking of them now is a bit harder.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4703e3e6@news.povray.org...
> Shay <Sha### [at] cccc> wrote:
>> Not quite. I suppose one set of commands would take care of a handful of
>> converters. The mesh-handling stuff? Well there's decimation for
>> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates
>> mesh models without a mouse (except me)?
>
>  I really don't understand your attitude. You are mocking the few
> examples given (and even quite illogically at that) and you refuse to
> see the big picture behind those examples.

     Erm... calm down Warp. I've read every post here and Shay has offered 
no less than anyone else. As it happens, from a non-programmers point of 
view, I think this thread has been a frenzy of what everyone *wants*, and in 
the end, I think nothing will happen directly resulting from this thread 
imo.

     It's a shame really, because the skill is here, in our very own 
community.

     (But, I'll be happy to download the 'new' version when it's ready).


         ~Steve~




>                                                          - Warp

Post a reply to this message

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