 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Rather than have an entire CLR, you could have the program structured to
> have C libraries (or C++ classes, I suppose), and clearly document how
> they're used. Then the SDL parser would invoke constructors building the
> classes, then invoke the "render" method.
That would mean that 1% of the povray community could benefit from that,
and it would not solve the problem that POV-Ray needs its SDL enhanced for
the rest of the people to use.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <no### [at] waycom> wrote:
> The Rendering engine should accept only strictly formatted bytecode.
Btw, this is a bad idea. It ties the hands of the developers.
It would make it impossible to change and improve the format of the
bytecode without breaking existing libraries.
It would work if the bytecode format could be PERFECTLY designed on
the very first try, and then fixed and engraved in stone. However,
developers are imperfect humans, so it's not gonna happen.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> The libraries would be written in C++, like the rest. No need for
> proprietary or non-free stuff.
> This would allow POV-Ray to be controlled by something else than
> "official" SDL (in a more open architecture), though the normal user
> would only see SDL.
How would the average user then use those libraries from the SDL?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <no### [at] waycom> wrote:
> I should say that a type of this is possible today...
> You could create a POV namespace and begin coding "objects" that exist
> in a structure and are able to be managed in source code, and stored in
> your own formats, either in your own library or in a custom "Scene" file.
That would not give any way of adding new features to POV-Ray, so it's
not a viable solution.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> The libraries would be written in C++, like the rest. No need for
>> proprietary or non-free stuff.
>
>> This would allow POV-Ray to be controlled by something else than
>> "official" SDL (in a more open architecture), though the normal user
>> would only see SDL.
>
> How would the average user then use those libraries from the SDL?
He would not. I mean : it would be transparent for the end user.
The "official SDL" parser will take that in charge.
where the user types...
sphere {<0,0,0>,2 pigment {Red}}
...the parser makes the appropriate library calls to put a red sphere in
the scene.
If I understood well the model you are advocating, it's :
layer 0 : core rendering engine
layer 1 : unique SDL, powerful enough to allow users to add complex functionality,
directly interfaced with layer 0
layer 2 : whatever people creates that makes use of the SDL
(please forgive, and correct if needed, any over-simplification, bad terminology...)
The "library" model would look like this :
layer 0 : core rendering engine
layer 1 : framework of libraries, providing interface to the core engine
layer 2 : official SDL, powerful enough to allow users to add complex functionality,
parsing manipulates libraries
layer 2 (alternative) : another SDL, or direct control by a modeller, ...
layer 3 : whatever people creates that makes use of the SDL
about the "library" model :
pros :
- more "open" architecture
- allows (for competent people) adding complex functionalities with (probably) more
power (speed) than an end-user SDL would allow, without touching the core engine,
though
- transparent to the end user
cons :
- adds another layer
- risk of multiplying library sets and versions (but there's a similar risk for core
engine)
I think that what you (globally) envision for the SDL is the way to go (making it much
powerful that it currently is). However there will be a compromise to find between
the
powerfulness (how far it can go) and user-friendliness (readability,
compatibility...),
and I think that having something between the core engine and the SDL would help ajust
the threshold without too much regrets.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was under the impression that the POV-Team sadly objects
to POV as a library backend and that this is even prohibited
by the distribution license, so the point seems to be moot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin a écrit :
> I was under the impression that the POV-Team sadly objects
> to POV as a library backend and that this is even prohibited
> by the distribution license, so the point seems to be moot.
This was to prevent someone to "hide" POV-Ray and use it as a rendering
engine for their own application.
We are talking (at least, I hope it's clear for everyone) about the
future POV-Ray 4.0 which will have an open-source licence, so
these restrictions will fall.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> I've been following the "new language SDL" thread for a while, but I
> don't know if this topic has been covered.
>
> Having been a fan of Borland, and now a user of Visual Studio, I would
> like to present the notion of using a language-independent framework,
> like the .net framework and then document it so well that us users can
> write our own front-end languages, a la Visual Basic, C#, J#, ASP.NET, etc.
>
> So there would be the ".POV Framework" and then C#.POV, J#.POV, Visual
> POV...
>
> Also, if I want to create a post-processor library, or an animation
> utility, or a complicated subroutine that can create a random moon for
> example, then the compiled libraries could work with all the
> implementations.
>
> Maybe (and this is a big maybe) we could boil down the SDL to a set of
> libraries that can be plugged in to Visual Studio, or used with Java or
> Perl, etc.
>
>
>
> I know this is a lot of work, but it would get the POV team out of the
> language biz and let them focus on thing like rendering engines and
> speed optimizations.
>
> Sorry if this has been brought up previously, but I missed it if it was.
>
>
Personally, I like the SDL just the way it is... Simple, mostly
predictable and easy to use... It has a few areas that could be
improved, as noted in previous posts, but overall its served the
community pretty well over the years...
I see no advantage to building "libraries" or porting it to other
(propriatary) languages and complicating it.
"The more complicated the plumbing, the easier it is to stop it up." to
quote Mr. Scott of Star Trek fame.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia nous apporta ses lumieres en ce 2007/10/03 16:50:
> I've been following the "new language SDL" thread for a while, but I
> don't know if this topic has been covered.
>
> Having been a fan of Borland, and now a user of Visual Studio, I would
> like to present the notion of using a language-independent framework,
> like the .net framework and then document it so well that us users can
> write our own front-end languages, a la Visual Basic, C#, J#, ASP.NET, etc.
>
> So there would be the ".POV Framework" and then C#.POV, J#.POV, Visual
> POV...
>
> Also, if I want to create a post-processor library, or an animation
> utility, or a complicated subroutine that can create a random moon for
> example, then the compiled libraries could work with all the
> implementations.
>
> Maybe (and this is a big maybe) we could boil down the SDL to a set of
> libraries that can be plugged in to Visual Studio, or used with Java or
> Perl, etc.
>
>
>
> I know this is a lot of work, but it would get the POV team out of the
> language biz and let them focus on thing like rendering engines and
> speed optimizations.
>
> Sorry if this has been brought up previously, but I missed it if it was.
>
>
You must make sure that the new, revamped SDL remain compatible with the actual
SDL, and remain capable to render existing scenes. Some deprecated and obsolete
"features" can be droped as were athmosphere and some others, but only you have
some good justification for doing so.
This compatibility must be maintained due to the huge library of premade
objects, textures, materials and various utilities distributed as .INC flies.
You also want to be able to render images from other peoples who may still be
using the 3.x version when you use the 4.x, and them to render yours.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you keep a blacklist of people who
ask questions about 3DFX products.
Alex McLeod a.k.a. Giant Robot Messiah
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Oct 2007 21:09:59 -0700, Darren New wrote:
> Mono is pretty
> good.
It has its good points and its bad points; I run openSUSE 10.2 here, and
I can tell you that the ZMD stuff is painfully slow, and Beagle is
horribly broken; both will bury the processor on my laptop.
For high-performance work like POVRay requires, I don't think it'd be the
right solution.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain a écrit :
> You must make sure that the new, revamped SDL remain compatible with the
> actual SDL, and remain capable to render existing scenes.
That will be a big issue.
Personally, I think that, while it might be possible to keep a good
amount of compatibility, 100% backwards compatibility shouldn't block
POV-Ray's evolution. Some things will have to be broken, for the best.
I think (but might be wrong) that writing some kind of converter, to take
care of what's been broken, should be preferred instead of making an half-baked
SDL for the sake of compatibility.
Compromises...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > How would the average user then use those libraries from the SDL?
> He would not. I mean : it would be transparent for the end user.
> The "official SDL" parser will take that in charge.
So what you are suggesting is that you can change the behavior of
existing features but you can't add new features?
That would be rather useless.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeff Houck <jho### [at] northrimnet> wrote:
> Personally, I like the SDL just the way it is... Simple, mostly
> predictable and easy to use...
... very limited and very slow.
Also, from core developement point of view, it's quite horrible.
For example, why do you think there's no eval() function in POV-Ray?
That is, a function which takes a string and evaluates this string
as if it was SDL (similar to how an #include "file" would do, but
with a string instead)?
Answer: Because the parser is a mess, full of kludges, burdened with
backwards-compatibility. For example, #macros are handy and powerful...
too powerful for their own good. #macros are one of the major reasons
why there's no eval() function in POV-Ray.
Adding new features to the parser is a real pain sometimes (I have
recent personal experience), mainly due to how the SDL works and is
parsed. For example, being able to insert a #declare almost anywhere
may feel handy, but is a nightmare to parse properly.
One thing I recently tried to achieve was string concatenation using
the + operator (as an alternative to the concat function). In the end
it seems that this would be really, really difficult to implement in
the current parser due to how interpreting # commands (which can appear
almost everywhere) works.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>>> How would the average user then use those libraries from the SDL?
>
>> He would not. I mean : it would be transparent for the end user.
>> The "official SDL" parser will take that in charge.
>
> So what you are suggesting is that you can change the behavior of
> existing features but you can't add new features?
No, I'm not.
If the libraries exposes every single renderer functionnality, up to its
lowest level (such as trace a ray, get turbulence at point,...), nothing
would prevent accessing them from the SDL to create new functionality.
All I suggest here is an abstraction layer between renderer and SDL,
but no limitations of what can be done in SDL.
(I have things to add, but I must go home, more later...)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Bryan Valencia <no### [at] waycom> wrote:
> > This would open the doors to things like...
>
> people writing powerful libraries for POV-Ray which are not portable and
> would require for people to install development environments in their
> system just to get the thing working.
>
> Also since the library is probably written in a language only 1% of
> POV-Ray users like, use or even understand, it would probably be pretty
> useless for almost everyone but the author himself.
>
> The good thing about the SDL is that the only requirement to use it
> is POV-Ray. That's it.
>
> --
> - Warp
I have to completely agree with Warp. I'd certainly write them in Scheme.
:)
Of course, it wouldn't be a problem if they were bytecompiled to some common
binary representation.
But, what really bothers me is that I'm not sure povray artists bother about
writing their own SDLs just to render a scene. I'd be interested to see the
opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
advanced SDL users...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> Of course, it wouldn't be a problem if they were bytecompiled to some common
> binary representation.
A library needs an interface to be used. That can't be bytecompiled.
> But, what really bothers me is that I'm not sure povray artists bother about
> writing their own SDLs just to render a scene. I'd be interested to see the
> opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> advanced SDL users...
I'm sure they use libraries for many things.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > Of course, it wouldn't be a problem if they were bytecompiled to some common
> > binary representation.
>
> A library needs an interface to be used. That can't be bytecompiled.
There're docs for that purpose. And if I'm not wrong, .Net's CLR provides
that interoperation between libraries written in different languages.
> > But, what really bothers me is that I'm not sure povray artists bother about
> > writing their own SDLs just to render a scene. I'd be interested to see the
> > opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> > advanced SDL users...
>
> I'm sure they use libraries for many things.
A library is not the same as a language. Except perhaps in the Lisp
world... :)
BTW, I replied this in the other thread, but find it relevant here too:
andrel <a_l### [at] hotmailcom> wrote:
> As you might have noticed, not everybody is convinced we should have one (SDL).
hello?! Drop povray's SDL and povray is just among many rendering engines.
I believe to be the crown jewel of povray!
We should have one and only povray SDL and it should have easy syntax and
semantics, should be mostly declarative interspeced with a few useful
control flow commands and should be modular. If someone wishes to program
in another language which suits his needs best, do it and create a program
in said language which compiles his scene or library to povray SDL, just
like today.
I think if povray loses its SDL, it'd lose its identity. If it shipped just
with some sort of bytecode VM for which lots of languages could compile to,
it'd still lose its identity.
Povray needs its own unique SDL, period.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> > A library needs an interface to be used. That can't be bytecompiled.
> There're docs for that purpose.
How is documentation going to help creating an interface to use a
precompiled library?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen escribió:
> "Rarius" <rar### [at] rariuscouk> wrote in message
> news:47041646$1@news.povray.org...
>> I must admit to liking the idea of a POV library... especially a .POV.
>> Being a software engineer by trade thats not really surprising!
>>
>> For many of us hard core coders that wouldn't be a bad solution. But it
>> would require a .NET developement environment and they don't come cheap
>> (unless your boss provides one like mine does!)
>>
>> POVRay has always been free and I hope it will remain so. If it suddenly
>> requires an expensive developement suite like VisualStudio that blows the
>> whole "free" thing out of the water.
>
> uhm, VisualStudio Express is free, isn't it ?
>
> cu!
They would have to pay me to get me to install VisualStudio.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, I'm home, here's the rest...
Let me tell something about an app that I use daily.
AutoCAD provides several ways to being programmed
and controlled by other programs. It has libraries
which exposes almost all of its functionalities.
At the lowest level, it's something called "ObjectARX",
which allows even the creation of new kind of objects,
and fully automated control rom another app. But it
requires the use of C++ or similar languages (using
it with C++ is documented, but there are people who
use delphi...)
At a slightly higher level, there are ActiveX controls,
which exposes less, but still allows most (except
the deepest ones) manipulations over the drawing's
database.
You can control it with anything that can control ActiveX,
but there are mainly two languages that are provided
and used to do this : good old LISP, which has been
extended to allow ActiveX calls, and VBA (which does
that naturally). Both have their pro and cons, but
are quite user friendly and allow both quick and simple
programs, and much more sophisticated stuff.
So, there is both an abstraction between the core and
and the highest level languages, while these languages
aren't that hard to learn for the end user (and there's
even a legacy one).
I simplified things a little, and, in fact, AutoCAD, being
20+ years old, is becoming a huge mess of piled stuff, especially
with their obsession of relea$ing a new one each f****** year.
Nevertheless, it's still a good example of an open architecture.
POV-Ray, which have the chance of being rewritten (most) entirely
would greatly benefit from that kind of openness, without sacrifying
ease AND power of a dedicated (new, enhanced) SDL.
BTW, someone talked about Flash ActionScript, I think that,
as part of these discussions, analysing how other apps does is
absolutely required.
Now, at this point of discussion, please note that
1) while I am not a total novice in programming and computing in
general, I am not an expert either, and expressing some high-end
programming concepts becomes difficult to do well in a conversation
with professionnal (or so) programmers.
2) this group is not the ideal space for such discussions, we would
really benefit of something where thematic discussions (general
architecture,
rendering, SDL(s), effects, materials, objects...) could take place.
We should beat it while it's hot.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > > A library needs an interface to be used. That can't be bytecompiled.
>
> > There're docs for that purpose.
>
> How is documentation going to help creating an interface to use a
> precompiled library?
It won't. The infrastructure is supposed to take care of that. If Visual
Basic or C# programs are compiled to the same "Common Language
Infrastructure", the .NET runtime knows how to handle the binary
interfacing of the code. The document documents the interface: here's a
function foo, which takes an argument bar of type foobar etc... should be
called from any language, using a particular syntax.
It's not different from calling precompiled native code from any language,
including C/C++: the linker is the infrastructure here providing the
glueing together of binaries compiled from different languages into the
same native interface.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis nous apporta ses lumieres en ce 2007/10/04 14:31:
> Warp <war### [at] tagpovrayorg> wrote:
>> nemesis <nam### [at] gmailcom> wrote:
>>>> A library needs an interface to be used. That can't be bytecompiled.
>>> There're docs for that purpose.
>> How is documentation going to help creating an interface to use a
>> precompiled library?
>
> It won't. The infrastructure is supposed to take care of that. If Visual
> Basic or C# programs are compiled to the same "Common Language
> Infrastructure", the .NET runtime knows how to handle the binary
> interfacing of the code. The document documents the interface: here's a
> function foo, which takes an argument bar of type foobar etc... should be
> called from any language, using a particular syntax.
>
> It's not different from calling precompiled native code from any language,
> including C/C++: the linker is the infrastructure here providing the
> glueing together of binaries compiled from different languages into the
> same native interface.
>
>
>
I don't think that .NET works on anything BUT Windows 2000, XP and Vista. Visual
Basic is a proprietary Microsoft implementation of Basic, and only run on a
Windows platform. C# comes from where? Is it from Microsoft?
--
Alain
-------------------------------------------------
Did you know that Al Capone's business card said he was a used furniture dealer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien nous apporta ses lumieres en ce 2007/10/04 11:29:
> Alain a écrit :
>
>> You must make sure that the new, revamped SDL remain compatible with
>> the actual SDL, and remain capable to render existing scenes.
>
> That will be a big issue.
>
> Personally, I think that, while it might be possible to keep a good
> amount of compatibility, 100% backwards compatibility shouldn't block
> POV-Ray's evolution. Some things will have to be broken, for the best.
>
> I think (but might be wrong) that writing some kind of converter, to take
> care of what's been broken, should be preferred instead of making an
> half-baked
> SDL for the sake of compatibility.
>
> Compromises...
>
> Fabien.
In a new SDL, you won't be able to maintain 100% backward compatibility.
One possible thing that may be done is to create some external scene converter
to recompose some droped features to the new features set, but that can be
almost impossible in several cases. Ever tried to convert the droped "halo"
feature to something else?
--
Alain
-------------------------------------------------
'Every man has his price. Mine is $3.95.'
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis a écrit :
> A library is not the same as a language. Except perhaps in the Lisp
> world... :)
Aaaah, the beauty of LISP.
I thought of proposing LISP as the new POV SDL language, but
I'm too young to die.
(for those who wonders, there's no difference between data and
functions, in LISP)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain a écrit :
> I don't think that .NET works on anything BUT Windows 2000, XP and
> Vista. Visual Basic is a proprietary Microsoft implementation of Basic,
> and only run on a Windows platform. C# comes from where? Is it from
> Microsoft?
I think that .NET is just to been seen as an *example* of such
interfacing concept, not as the way to go for POV-Ray.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain a écrit :
> In a new SDL, you won't be able to maintain 100% backward compatibility.
Yep.
> One possible thing that may be done is to create some external scene
> converter to recompose some droped features to the new features set, but
> that can be almost impossible in several cases. Ever tried to convert
> the droped "halo" feature to something else?
If the converter manages to do it right in, say, 95% of cases, won't it
already be good enough ? That's a trade-off I would accept readily, in
exchange of more speed and flexibility.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> I don't think that .NET works on anything BUT Windows 2000, XP and Vista. Visual
> Basic is a proprietary Microsoft implementation of Basic, and only run on a
> Windows platform. C# comes from where? Is it from Microsoft?
it was just an example. But anyway, yes, you can get .NET to run under
Linux via mono. Of course, be sure to get yourself patent coverage from
the lame Novell/M$ deal... :P
I was just pointing out to Warp that once you get a common binary
infrastructure and get your code compiled to it, documentation is all you
need to call functions written in other languages: name of the function,
arguments, argument types and returned values. It's how you are able to
call C/C++ routines from, say, a Delphi program: in the end it's just
binary routines calling other native binary routines.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis escribió:
> I was just pointing out to Warp that once you get a common binary
> infrastructure and get your code compiled to it, documentation is all you
> need to call functions written in other languages: name of the function,
> arguments, argument types and returned values. It's how you are able to
> call C/C++ routines from, say, a Delphi program: in the end it's just
> binary routines calling other native binary routines.
COM is a binary interface too, it's also from Microsoft but I doubt
there is any patent hell about it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jeff Houck <jho### [at] northrimnet> wrote:
>> Personally, I like the SDL just the way it is... Simple, mostly
>> predictable and easy to use...
>
> ... very limited and very slow.
>
> Also, from core developement point of view, it's quite horrible.
> For example, why do you think there's no eval() function in POV-Ray?
> That is, a function which takes a string and evaluates this string
> as if it was SDL (similar to how an #include "file" would do, but
> with a string instead)?
> Answer: Because the parser is a mess, full of kludges, burdened with
> backwards-compatibility. For example, #macros are handy and powerful...
> too powerful for their own good. #macros are one of the major reasons
> why there's no eval() function in POV-Ray.
>
> Adding new features to the parser is a real pain sometimes (I have
> recent personal experience), mainly due to how the SDL works and is
> parsed. For example, being able to insert a #declare almost anywhere
> may feel handy, but is a nightmare to parse properly.
> One thing I recently tried to achieve was string concatenation using
> the + operator (as an alternative to the concat function). In the end
> it seems that this would be really, really difficult to implement in
> the current parser due to how interpreting # commands (which can appear
> almost everywhere) works.
>
I was unaware that the parser was in such sad shape... I'm more of an
end-user than developer in this case...
I've been trying to follow both of the SDL threads and one thing has
occurred to me, why not expose the core interface API to a language like
Python? It's cross-platform, object oriented and has been used
successfully as a scripting interface to a number of projects.
Currently, we're using Python-Ogre to prototype a game framework and the
implementation works great! Python has a number of programming tools
available across a number of OS platforms, AND, it's not a hard language
to learn or master...
Just a thought...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> It's not different from calling precompiled native code from any language,
> including C/C++: the linker is the infrastructure here providing the
> glueing together of binaries compiled from different languages into the
> same native interface.
A precompiled library alone is useless in C/C++. You need the non-compiled
public interface to use the library.
That's exactly the problem: If you create a POV-Ray library using
language X, it must be usable without the need for the user to have
the developement environment necessary to write in language X. It must
be usable from POV-Ray directly, using its native scripting language.
How are you going to use it without an interface?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeff Houck <jho### [at] northrimnet> wrote:
> I've been trying to follow both of the SDL threads and one thing has
> occurred to me, why not expose the core interface API to a language like
> Python?
Changing radically the scripting language is not going to be well received.
Personally I dislike python in particular because of its enforced
whitespace interpretation.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jeff Houck <jho### [at] northrimnet> wrote:
>> I've been trying to follow both of the SDL threads and one thing has
>> occurred to me, why not expose the core interface API to a language like
>> Python?
>
> Changing radically the scripting language is not going to be well received.
Well, that certainly could be an issue though I don't see how it can be
avoided to some extent. It's all speculation I guess...
On the other hand, I could code up an "unofficial" Python binding
anyway... Just need the source and a little time...
>
> Personally I dislike python in particular because of its enforced
> whitespace interpretation.
That's one of the things I like... to each his own they say.... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> A precompiled library alone is useless in C/C++. You need the non-compiled
> public interface to use the library.
That's a problem with C/C++ and their reliance on header files for function
prototypes AFAIK. Besides, even then, with documentation about functions
written in other languages, even in a C/C++ enviroment you can call these:
just write the proper header files by prototyping the functions as
documented.
Say you write a class in JRuby and bytecompile it. You can use that class
from a regular Java problem without worries.
> It must
> be usable from POV-Ray directly, using its native scripting language.
> How are you going to use it without an interface?
I agree povray *must* have its own scripting language. And if it's JITted,
only the better. I was just pointing out that it is possible to interface
with compiled code given a common binary format, documentation and support
from the infrastructure (compilers, linkers, runtime).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Let me give the perfect example of what I mean.
I work at a mortgage company. We internally use a third-party system to
write our mortgage application software. This tool is rife with handy
components to make processing mortgage applications easier.
In the current version of the system, they are using a scripting
language that's built in. But while the mortgage tools are awesome, the
programming language (to borrow from Shakespeare) "bloweth chunks".
So, their next-gen suite, which we are just starting to convert to, is a
set of components that are integrated into Visual Studio. Not just a
DLL, but a whole mortgage processing component suite, all placed right
into the toolbar for dragging and dropping into our software.
The net (bad pun) result: a great tool package that was held back by a
weak script language has been set free. We can now create anything from
ASP.NET and webservices to C#.NET VB.NET, J#, or even console apps. And
it doesn't matter which development language we use, the CLR understands
it all.
If there was a suite of POV components that plugged into Visual Studio
Express (the FREE version), we could let Microsoft's strong languages
enhance POV's incredible rendering engine.
Now, the current POV SDL bloweth not chunks, but I still contend that
opening the architecture so that we CAN access the POV internal
structures would make it a far more powerful tool.
Plus, it should still be possible to keep the existing SDL and use it as
a standalone app, even if they integrate the POV engine into a framework
like .net.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bryan Valencia <no### [at] waycom> wrote:
>> The Rendering engine should accept only strictly formatted bytecode.
>
> Btw, this is a bad idea. It ties the hands of the developers.
> It would make it impossible to change and improve the format of the
> bytecode without breaking existing libraries.
>
> It would work if the bytecode format could be PERFECTLY designed on
> the very first try, and then fixed and engraved in stone. However,
> developers are imperfect humans, so it's not gonna happen.
>
thats just wrong. thats like saying that Microsoft can never improve
Word because Word for DOS version 1 doesn't have that.
Bytecode format can be versioned just like all applications and
languages are today. Like in HTML, they are getting rid of <b> and </b>
and changing to <span style="font-weight:80"> this </span>
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> The libraries would be written in C++, like the rest. No need for
>> proprietary or non-free stuff.
>
>> This would allow POV-Ray to be controlled by something else than
>> "official" SDL (in a more open architecture), though the normal user
>> would only see SDL.
>
> How would the average user then use those libraries from the SDL?
>
in this environment, libraries can be written in any .net language
(assuming that Visual Studio is the "framework" being used)
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> I was under the impression that the POV-Team sadly objects
> to POV as a library backend and that this is even prohibited
> by the distribution license, so the point seems to be moot.
It's ok, we're just brainstorming.
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <no### [at] waycom> wrote:
> Bytecode format can be versioned just like all applications and
> languages are today. Like in HTML, they are getting rid of <b> and </b>
> and changing to <span style="font-weight:80"> this </span>
Dragging backwards compatibility is a bad thing for improvement.
HTML is a mess exactly because of that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <no### [at] waycom> wrote:
> in this environment, libraries can be written in any .net language
> (assuming that Visual Studio is the "framework" being used)
Could we *please* stop talking about making Windows-only features.
Pretty please? POV-Ray is not. So just stop, please.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia escribió:
> Warp wrote:
>> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>>> The libraries would be written in C++, like the rest. No need for
>>> proprietary or non-free stuff.
>>
>>> This would allow POV-Ray to be controlled by something else than
>>> "official" SDL (in a more open architecture), though the normal user
>>> would only see SDL.
>>
>> How would the average user then use those libraries from the SDL?
>>
> in this environment, libraries can be written in any .net language
> (assuming that Visual Studio is the "framework" being used)
>
I'll have to put it in this language, sorry: Screw .NET
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Rather than have an entire CLR, you could have the program structured to
>> have C libraries (or C++ classes, I suppose), and clearly document how
>> they're used. Then the SDL parser would invoke constructors building the
>> classes, then invoke the "render" method.
>
> That would mean that 1% of the povray community could benefit from that,
The point of doing it that way would primarily be to allow those writing
the SDL to use one of the many languages that already exist to avoid
having to reimplement anything in the SDL except the ray-tracing. Need
formatted input/output? Need to read CSV files? Want to store objects or
libraries in a database, or in google-file-system? Want to send a
message over a socket each time a frame finishes? If you use an existing
language that can interface to C, like Java, Tcl, Python, Lisp, etc etc
etc, you get all that sort of stuff "for free". Of course, munging your
SDL syntax to match the language you pick can be a bit problematic, but
it's not *that* hard to solve, especially if you pick an appropriate
"base" langauge.
Hope that clarifies.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> If there was a suite of POV components that plugged into Visual Studio
> Express (the FREE version), we could let Microsoft's strong languages
> enhance POV's incredible rendering engine.
>
You are forgetting (or ignoring) that VS is Windows only. POV-Ray is
*NOT* limited to Windows only.
-=- Larry -=-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.47055ba7bcc3cc02773c9a3e0@news.povray.org>,
nam### [at] gmailcom says...
> Warp <war### [at] tagpovrayorg> wrote:
> > A precompiled library alone is useless in C/C++. You need the non-com
piled
> > public interface to use the library.
>
> That's a problem with C/C++ and their reliance on header files for functi
on
> prototypes AFAIK. Besides, even then, with documentation about functions
> written in other languages, even in a C/C++ enviroment you can call these
:
> just write the proper header files by prototyping the functions as
> documented.
>
> Say you write a class in JRuby and bytecompile it. You can use that clas
s
> from a regular Java problem without worries.
>
> > It must
> > be usable from POV-Ray directly, using its native scripting language.
> > How are you going to use it without an interface?
>
> I agree povray *must* have its own scripting language. And if it's JITte
d,
> only the better. I was just pointing out that it is possible to interfac
e
> with compiled code given a common binary format, documentation and suppor
t
> from the infrastructure (compilers, linkers, runtime).
>
Hmm. If I get what you are saying, then I may agree with you. Make the
POVRay system into a library, which is of a type capable of easily being
integrated into any other language, while "still" keeping an internal
language for the scene. In other words, make similar to what it would be
if you wanted to use IE using COM:
a = createobject("explorer.application")
if typename(a) = "explorer" then
a.load("c:\Mydocs\fred.html")
end if
The language you use to tie the engine into shouldn't care what the
engine was written in, as long as the library is one that can be easily
linked/instanced/whatever. For the current version this is pointless,
since there are issues with having to have it announce its copyrights,
etc. (which I suggested one possible solution to, at least under
windows), but 4.0 is supposed to be a lot nicer about that sort of
thing, allowing it to be more closely integrated.
This however says *nothing* about what the SDL itself should be doing,
nor about how anything, beyond the functions/events supported in that
interface, allow for integration of plugins or any other elements that
are "specific" to the engine, and thus "not" part of the application its
been embedded into.
--
void main () {
If Schrödingers_cat is alive
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Oct 2007 15:57:22 -0700, Bryan Valencia wrote:
> If there was a suite of POV components that plugged into Visual Studio
> Express (the FREE version), we could let Microsoft's strong languages
> enhance POV's incredible rendering engine.
Let me say this again: This is great if you use windows, but NOT
EVERYONE USES WINDOWS!!!!!
(Sorry, I just get tired of repeating myself here)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Oct 2007 14:58:54 -0300, Nicolas Alvarez wrote:
> They would have to pay me to get me to install VisualStudio.
They couldn't pay me enough, and I have an MSDN subscription for work.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia a écrit :
> Warp wrote:
>> Bryan Valencia <no### [at] waycom> wrote:
>>> The Rendering engine should accept only strictly formatted bytecode.
>>
>> Btw, this is a bad idea. It ties the hands of the developers.
>> It would make it impossible to change and improve the format of the
>> bytecode without breaking existing libraries.
>>
>> It would work if the bytecode format could be PERFECTLY designed on
>> the very first try, and then fixed and engraved in stone. However,
>> developers are imperfect humans, so it's not gonna happen.
>>
> thats just wrong. thats like saying that Microsoft can never improve
> Word because Word for DOS version 1 doesn't have that.
Word has been improved since version 1 ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien escribió:
>
> Word has been improved since version 1 ?
>
> Fabien.
I don't know if it has been improved, but a few broken features were
fixed, and new broken features were introduced. Percentage of brokenness
is around the same, though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <47054da9@news.povray.org>:
> Changing radically the scripting language is not going to be well received.
I think you miss a point: if POV-Ray's rendering features are available as
library functions call from some languages or, even better, from several
languages, you can then write in that language whatever parser you want.
Let us say, for the sake of the argument, that these features are accessible
as a Caml module. Then you can write a parser for the SDL, the very current
SDL, in Caml. Maintaining a separate parser like that would be easier than
maintaining a parser built in the core system, provided the language is good
for parsers (and Caml is good for parsers).
Now, a basic user of POV-Ray can write his scene in plain old SDL, the
front-end will automatically call the Caml parser, and the user does not see
any change.
On the other hand, an user that want to do complex programmatic features in
his scene can write them in Caml, and plug the result in his scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas George wrote in message <4707448b$1@news.povray.org>:
> I think you miss a point: if POV-Ray's rendering features are available as
> library functions call from some languages or, even better, from several
> languages, you can then write in that language whatever parser you want.
Just to have things clear, here is the outline of a plan for this solution.
1. Make the rendering features of POV-Ray into a clean c++ library. That
gives us libpov4.so and pov4.hh.
2. Chose a language that you like and that makes writing parsers and
interpreters easy. Let us say, just to avoid writing "that language"
everywhere, that this is Caml -- if you prefer INTERCAL, replace
everywhere.
3. Write a wrapper library to use libpov4.so from Caml.
4. Write a clean parser and interpreter for the current SDL in Caml.
5. Chose a language that you like and that can easily be fully embedded.
Again, just to have a name, let us say this is Lua.
6. Write a wrapper library to use libpov4 from Lua.
7. Extend the parser-interpreter to allow loading new features from a shared
object and calling them.
8. Build a front-end, linked with libpov4.so, including 3, 4, 6, and 7 (and
making sure that 7 is directly aware of 6).
Now, let us consider the result:
- Current basic users of POV-Ray just call the resulting binary (8) with
their unchanged scenes. The scene is parsed and interpreted by 4 and
rendered by 1.
- Developers of POV-Ray can slowly extend the parser-interpreter to make the
SDL a little bit less clumsy (with "for" loops for example).
- Medium-level users of POV-Ray can learn Lua, and include Lua code from
their SDL scenes.
- Advanced users of POV-Ray can add brand new features as c++ objects.
- Other advances users can write wrappers around libpov4.so for other
languages, and write their scenes with their favorite language. Wrappers
that are good code can be included in the official POV-Ray distribution.
In the long run, I have the hope that someone could write, for example, a
robot in Scheme, some other person could write a space shuttle in Perl, a
third may write a solar system (with accurate orbits) in Fortran, and a
basic user could just use these scene parts from his SDL scene:
#declare Robot = friendly_robot {
left_shoulder 90
right_shoulder 20
...
}
#declare Planets = solar_system { 2007, 10, 06, 09, 56, 00 }
...
(Well, actually, I do not hope exactly that, since I hope that Fortran would
be really dead by then.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, how do you envision the basic user being able to write shaders in
this system? Note that the basic user wants to use the current SDL, only
enhanced with shaders.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
