Tim Nikias v2.0 wrote:
>You might want to take a look at "Mechsim".
>Creating an inbuilt physical simulation algorithm
>with other techniques than that seems to me
>quite impossible.
>
>The problem with scripting them into the core
>of POV-Ray is that most of the time, several
>approaches exist, and they might be quiet
>contradictory in setting them up. AFAIK,
>POV-Ray 4 should have better support
>for plug-ins.

Mechsim is certainly a great piece of code,
and I have had a brief look at it, although
I haven't used it in any of my own projects
as of yet. But what I have in mind goes far
beyond just basic mechanics simulation. For
instance, consider the differece in lights
and rendering between POV-Ray and Radiance:
whereas POV simply uses a color float to
specify the intensity and hue of a light
source, Radiance takes a different approach,
specifying the lights in a more scientific
way. I imagine that such an approach could
be taken a lot further, though. For instance:
working with solid volumes (in the simulation,
of course - it would be pointless in the actual
rendering) rather than surface-based objects
with insides and outsides; specifying materials
in terms of elements and their characteristics,
such as density, surface properties and so on,
thus incorporating pigment, normal and media
statements into a single grammar based in
chemistry and - ultimately, but still far out
of reach - particle physics; define groups of
objects as "organisms", interacting according
to kinematics, evolutionary algorithms, etc.

Even if it was possible, it probably wouldn't
be worthwile to incorporating such a diverse
set of functions into the core of POV-Ray, and
better support for plugins is always a good
thing, of course. But adapting the program to
scientific definitions and terminology in more
respects than just the optical is a prerequisite
for making the plugin system coherent from a
conceptual viewpoint.

(You should consider all of this as musings
of a speculative mind with heavy utopian
leanings, thinking beyond all restraints of
actual computing power - I run POV on a puny
32 Mb RAM! My interest lies primarily in the
discussion: the potential of simulation, not
the actual state of affairs.)

Post a reply to this message

Althouth the Utopian Idea of defining
Objects via chemistry-based, scientific
properties like density, viscosity, termal
reaction etc would go way beyond
anything a normal User would achieve,
it is interesting. I mean, who would actually
go create the reflective sphere with a
checkered plane, using lead, different
sets of marble, and go look up their
proper values?

What you're actually proposing is something
like a world-simulation, which should take
all known physical behaviours into account.
Problem with that is, that there are sometimes
quiet a diversity of approaches on how to
model and accurately put things into values.
Just take the different color-models,
RGB, which POV-Ray uses, is only one, and
there are several out there which may be of
better use for certain tasks.

I think a less Utopian Approach would be to
model different but specialized simulations. E.g.
one for fire, another for liquids, mass-particle
effects, with and without particle-interaction,
lighting models...
Once a basic setup is chosen (like: what of a
lightray is saved and handed down the recursive
tree: direction, reflection-points, intensity, color,
etc?), Plug-Ins should make use of different
properties and enhance/replace them. As for
simulations themselves (heat, for example), the
scene has to be preparsed somehow (at least
I'd expect that, using voxels or such), and then
the heat-simulation would run by itself. Introducing
a cold liquid? The liquid simulation takes care of
"being liquid", but the the heat-simulation reads
where the liquid is going and simulates heat-
properties for it. Combining both would make
it more difficult to properly set things up.

Just take my LSSM, the Liquid-Surface-Simulation-
Macros, as an example. They're only of use for
areas where the water is in an enclosed space, like
a pond, a swimming pool, or such. They create
near-realistic effects for waves. Aside of that, they
can't be used to simulate a burst of water into
a tunnel. Its just the surface. IMHO, taking care
of small parts, and combining them in the end, is
better, than having a huge, combined simulation,
where certain parts may be really redundant.


-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


> >You might want to take a look at "Mechsim".
> >Creating an inbuilt physical simulation algorithm
> >with other techniques than that seems to me
> >quite impossible.
> >
> >The problem with scripting them into the core
> >of POV-Ray is that most of the time, several
> >approaches exist, and they might be quiet
> >contradictory in setting them up. AFAIK,
> >POV-Ray 4 should have better support
> >for plug-ins.
>
> Mechsim is certainly a great piece of code,
> and I have had a brief look at it, although
> I haven't used it in any of my own projects
> as of yet. But what I have in mind goes far
> beyond just basic mechanics simulation. For
> instance, consider the differece in lights
> and rendering between POV-Ray and Radiance:
> whereas POV simply uses a color float to
> specify the intensity and hue of a light
> source, Radiance takes a different approach,
> specifying the lights in a more scientific
> way. I imagine that such an approach could
> be taken a lot further, though. For instance:
> working with solid volumes (in the simulation,
> of course - it would be pointless in the actual
> rendering) rather than surface-based objects
> with insides and outsides; specifying materials
> in terms of elements and their characteristics,
> such as density, surface properties and so on,
> thus incorporating pigment, normal and media
> statements into a single grammar based in
> chemistry and - ultimately, but still far out
> of reach - particle physics; define groups of
> objects as "organisms", interacting according
> to kinematics, evolutionary algorithms, etc.
>
> Even if it was possible, it probably wouldn't
> be worthwile to incorporating such a diverse
> set of functions into the core of POV-Ray, and
> better support for plugins is always a good
> thing, of course. But adapting the program to
> scientific definitions and terminology in more
> respects than just the optical is a prerequisite
> for making the plugin system coherent from a
> conceptual viewpoint.
>
> (You should consider all of this as musings
> of a speculative mind with heavy utopian
> leanings, thinking beyond all restraints of
> actual computing power - I run POV on a puny
> 32 Mb RAM! My interest lies primarily in the
> discussion: the potential of simulation, not
> the actual state of affairs.)
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18.09.2003

Post a reply to this message

In article <3f6d951a@news.povray.org>,
 "Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote:

>  AFAIK,
> POV-Ray 4 (which is a long way off, and
> don't think about asking about it: it's finished
> when its finished, as always with POV-Ray,
> and I don't object) should have better support
> for plug-ins (in other words: other support
> than just POV-Script Include-Files) in order
> to make writing own enhancements easier
> and faster (as POV-Script is quiet slow).

And where did you hear this?

As you say, it's a long way off, too far off to say anything definite 
about plugin support. However, historically, native plugin support has 
never been implemented because there is no platform-independant way of 
doing it. POV could use precompiled bytecode plugins instead, but then 
there's no reason not to just include the source files: the bytecode 
compiler could (and almost certainly would) be built into POV. The 
current scripting language is slow because it is interpreted directly, 
compiling to bytecode first can be much faster, and would work just fine 
with the current system of include files.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

I've heard rumours, so that's the reason for a
"AFAIK". I don't know who originally mentioned
it, and perhaps it was just a discussion amongst
those not able to program POV themselves, but
what they would like to see. Not sure.

Still, even a faster compiler could count as
being Plug-In Support. I was just thinking
in terms of Cinema4D, Maya and such, where
"outside" scripts can be used quiet efficiently to
enhance the GUI (although POV doesn't really
have its own one, but a Free Script Editor,
right? I mean, its not programmed by the
POV-Team, is it?) and modelling aspects.
The Include-Files of today may count as
plug-ins, but getting something which may make
them parse faster (more like bytecode, as
you mentioned, or easier handling as external
programms to be called inbetween frames) would
be very much appreciated (at least by me, I
tend to write these huge parsing-intensive scripts...).

Other than POV 4 being a dream, there is no
actual code there yet, is there? I mean, gathering
feature-ideas and such is in progress, perhaps
even spending some thought in how to go
about it, but no real code?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


>
> >  AFAIK,
> > POV-Ray 4 (which is a long way off, and
> > don't think about asking about it: it's finished
> > when its finished, as always with POV-Ray,
> > and I don't object) should have better support
> > for plug-ins (in other words: other support
> > than just POV-Script Include-Files) in order
> > to make writing own enhancements easier
> > and faster (as POV-Script is quiet slow).
>
> And where did you hear this?
>
> As you say, it's a long way off, too far off to say anything definite
> about plugin support. However, historically, native plugin support has
> never been implemented because there is no platform-independant way of
> doing it. POV could use precompiled bytecode plugins instead, but then
> there's no reason not to just include the source files: the bytecode
> compiler could (and almost certainly would) be built into POV. The
> current scripting language is slow because it is interpreted directly,
> compiling to bytecode first can be much faster, and would work just fine
> with the current system of include files.
>
> -- 
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18.09.2003

Post a reply to this message

On Mon, 22 Sep 2003 21:06:04 +0200, "Tim Nikias v2.0" <no_lights (@)
digitaltwilight.de> wrote:
> Other than POV 4 being a dream, there is no
> actual code there yet, is there?

Every small step between start and finish is a progress :-)
This includes every new include file, every insert menu, every tested feature
in own patch, every typo found in documentation.

ABX

Post a reply to this message

Tim Nikias v2.0 wrote:
> 
> Still, even a faster compiler could count as
> being Plug-In Support. I was just thinking
> in terms of Cinema4D, Maya and such, where
> "outside" scripts can be used quiet efficiently to
> enhance the GUI (although POV doesn't really
> have its own one, but a Free Script Editor,
> right? I mean, its not programmed by the
> POV-Team, is it?)

You do realized that Cinema4D and Maya as well as the WinPOV GUI are not 
platform independant (both Cinema4D and Maya are available for multiple 
platforms but only through a lot of platform specific work you can bet).

Any 'plugin' feature in POV 4 will probably have much more similarity to 
  POV-Ray 3.5 user defined functions and POVMan shaders than to a plugin 
system you might know from another program.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 2 Sep. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

I know that GUI wouldn't be the perfect
example...

But take my LSSM, or Rune's and my
particle system. If one could easily set
things like
"lssm_simulation_steps" in global-settings,
and then have some object like
lssm_rectangle{ Corner_1, Corner_2, Corner_3}
and *additionally* have them parse faster,
by just putting a pre-parsed bytecode in
some directory for POV-Ray to find
it, that would be neat! Right now one has
to include the files, and they don't have
much access to POV-Internal stuff like
rays for lighting calculations and such.

For platform-independance, I guess a
faster parser could be quiet sufficient,
but some more object-oriented style
would be nice. E.g. macro's with same
name, but if I leave out a texture, it
will still work:
#macro Tex_Translate(Position,Texture)
 texture{Texture translate Position}
#end
#macro Tex_Translate(Texture)
 texture{Texture}
#end
#macro Tex_Translate(Position)
 texture{Default_Texture translate Position}
#end

This would require POV to understand the
difference of vectors/floats/textures/objects
etc for parameters, but that would make some
handling easier.

All in all, I'm no expert on this, but a
functionality which would writing own
camera-functions like Slime (if I'm not
mistaken) did, or how the original isosurface
made it into MegaPOV, easier, without
compiling your own POV-Version, that
would be great.

But I'm probably annoying you with
my ignorant rambling, its just a dream
of mine... ;-)

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de

> Tim Nikias v2.0 wrote:
> >
> > Still, even a faster compiler could count as
> > being Plug-In Support. I was just thinking
> > in terms of Cinema4D, Maya and such, where
> > "outside" scripts can be used quiet efficiently to
> > enhance the GUI (although POV doesn't really
> > have its own one, but a Free Script Editor,
> > right? I mean, its not programmed by the
> > POV-Team, is it?)
>
> You do realized that Cinema4D and Maya as well as the WinPOV GUI are not
> platform independant (both Cinema4D and Maya are available for multiple
> platforms but only through a lot of platform specific work you can bet).
>
> Any 'plugin' feature in POV 4 will probably have much more similarity to
>   POV-Ray 3.5 user defined functions and POVMan shaders than to a plugin
> system you might know from another program.
>
> Christoph
>
> -- 
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 2 Sep. 2003 _____./\/^>_*_<^\/\.______
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18.09.2003

Post a reply to this message

in news:3f6f5605@news.povray.org Tim Nikias v2.0 wrote:

>  E.g. macro's with same
> name, but if I leave out a texture, it
> will still work:
> #macro Tex_Translate(Position,Texture)
>  texture{Texture translate Position}
> #end
> #macro Tex_Translate(Texture)
> 

Something like this?:
http://www.python.org/doc/current/tut/node6.html#SECTION0067100000000000
00000   
4.7 More on Defining Functions and further
(there may be a few zeros broken off that link)


Regarding speed, when I made my param.inc file I also did it in python. 
The original param.inc only used macros and was quite a bit slower that 
its Python equivalent. After rewriting param.inc to using functions the 
parse time of both seemed the same at first sight, but SDL was actually 
faster. In the same time it took to run the python program, SDL did the 
same calculations and also parsed a million triangles. The resulting 
file generated by python still had to be read and parsed by POV-Ray 
then. So SDL isn't that bad in all cases. In one of the old MegaPOV 
versions is a patch for speeding up macros that also helped a lot. And 
when I see the speeds that can be reached with for example the 
'interpreted' version of ocaml, there must still be some room for 
improvement somewhere.


Regarding plugins, why do so many people want these and why do so few 
people suggest going in the "opposite way". Chop POV-Ray in two/three 
pieces, a raytracing libray (+parser) +API and have the SDL as its prime 
implementation. Then everybody could write their scenes in any language 
somebody generated a binding for. You could even plug POV-Ray into one 
of the big 3D apps, although you probably could do now too if somebody 
wrote the stuff that is needed inbetween.

All the above is offcoarse written without being hamperd by any 
knowledge of the matter.

Ingo

Post a reply to this message

ingo wrote:
> 
> Regarding speed, when I made my param.inc file I also did it in python. 
> The original param.inc only used macros and was quite a bit slower that 
> its Python equivalent. After rewriting param.inc to using functions the 
> parse time of both seemed the same at first sight, but SDL was actually 
> faster. In the same time it took to run the python program, SDL did the 
> same calculations and also parsed a million triangles. The resulting 
> file generated by python still had to be read and parsed by POV-Ray 
> then. So SDL isn't that bad in all cases.

I always had the impression python is quite slow.  The first HTML 
preprocessor i used for my website (ahts) was implemented in python and 
it was incredibly slow.  I currently use your python tool for formatting 
pov code in HTML and i also can see the slowdown on pages with many code 
blocks.

Not directly related but i think param.inc would be a nice feature to be 
implemented internally - it would be quite similar to the bicubic patch 
object which is also represented as a mesh.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 2 Sep. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

in news:0v4### [at] tritonschunteretctu-bsde Christoph Hormann 
wrote:

> I always had the impression python is quite slow. 

For what it's worth, a nice comparisin of a few langauages:
http://www.bagley.org/~doug/shootout/
http://www.bagley.org/~doug/shootout/craps.shtml
How would SDL score?

Ingo

Post a reply to this message