 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Nice idea, but I doubt it will fly.
Rarius
"Bryan Valencia" <no### [at] way com> wrote in message
news:47040096$1@news.povray.org...
> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was just thinking of divorcing the SDL from the scene/render/animation
engine in such a way that you can create languages that generate code
that can be 'executed' by a CLR
(http://en.wikipedia.org/wiki/Common_Language_Runtime).
So the POV engine would become a "Framework" that no longer parses
strings, but instead just executes some minimalist bytecode. Then the
"languages" just have to create the SDL bytecode and pass it to the .POV
CLR.
This kind of architecture could lead to the same kind of environment we
have in .net today... a compiled C# object can be easily dropped into a
J# application, or VB.NET application (true language independence). Now
I know that this does not (directly) address the Linux and Mac worlds
(sorry) - but the idea holds true regardless.
The Rendering engine should accept only strictly formatted bytecode.
Languages should be completely abstracted from the renderer.
This would open the doors to things like...
Webservices
Web-based rendering
network job-sharing (want to use 30 PCs to render your animation? want
to have a dedicated prerenderer, renderer, and post-processor?)
Oh yeah, and if POV could be plugged into Visual Studio (and the
linux/mac equivalents), you get...
. source control integration
. database access (want to store 20,000 asteroids in an Oracle database?)
. Web access (want to access Google Maps to get map data for a render?)
. Complex math, variable scopes, recursion, inheritance, "AI"
I think the possibilities are pretty limitless.
Rarius wrote:
> 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.
>
> Nice idea, but I doubt it will fly.
>
> Rarius
>
>
> "Bryan Valencia" <no### [at] waycom> wrote in message
> news:47040096$1@news.povray.org...
>> 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.
>
>
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen wrote:
> "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!
Yes, I am using VS Express 2008 Beta right now. It so totally rocks!
http://msdn2.microsoft.com/en-us/express/future/bb421473.aspx
--
---
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:
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen <zeg### [at] povplacecom> wrote:
> > 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 ?
Portability anyone?
Not everyone uses Windows, you know.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Then all you have to do is make your objects able to export themselves
in a POV format, like:
public class Sphere()
{
public String ToPOV()
{
/*build the string to output a sphere and it's properties here*/
}
}
Anyhow, this could be done now, but it would be better not to have to
render the scene as text... it would be better if we could use some kind
of bytecode that didn't barf on typos :)
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp 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.
>
But the thing is that POV could maintain their OWN version of the
language if they wanted. Just like anyone can use the Microsoft .net
framework documentation to make cobol.net or lisp.net if they were so
inclined.
My point is that the engine should be divorced from the language.
--
---
Bryan Valencia
- I'd rather live with false hope than with false despair.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Oct 2007 16:15:37 -0700, Bryan Valencia wrote:
> This would open the doors to things like...
Smaller groups of people with knowledge in how to code up a scene in a
given language.
This seems like a great way to fragment the community....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Oct 2007 01:16:33 +0200, Zeger Knaepen wrote:
> uhm, VisualStudio Express is free, isn't it ?
Doesn't do the non-Windows crowd much good, though.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Zeger Knaepen nous apporta ses lumieres en ce 2007/10/03 19:16:
> "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!
Will it run on a Mac?
Will it run on Linux or Unix? ANY version?
Will it run on... anything NOT windows?
Will it run on older versions of windows?
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever brought your
computer to its knees by mistakenly launching 64 simultaneous frames to be
traced, while trying to maximizing the benefits of parallelizing them.
Carsten Whimster
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Will it run on... anything NOT windows?
Well, there's Mono. And if you're talking primarily stdio-level of
interaction (i.e., non-GUI version like the Linux pov-ray), Mono is
pretty good.
(Only because you asked, mind... :-)
--
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:
> So the POV engine would become a "Framework" that no longer parses
> strings, but instead just executes some minimalist bytecode.
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.
Other languages could be written to also do the same sort of thing.
I contrast this with what you seem to be describing, which seems to be
"output the result of parsing in a simpler form, then invoke a runtime
to interpret it."
I already have programs(*) that take a "simpler" language and output 3.6
SDL code, then invoke POV-Ray to get the images, along with (in this
case) the web pages that link the images together. That POV has a
well-documented input format is what draws me to it.
Doing it my way falls down when you want to have "subroutines" that were
written in a different language and you want to use them in your scene,
but you don't have the proper interpreter. My way has the advantage that
there are already a bunch of languages that easily link to C (and
probably C++ with work), so nobody has to write code that loops, does
math, does I/O, etc etc etc. In other words, the library would embody
the ray-tracing code and nothing else, in much the same way that emacs
handles buffers and files and edits, and leaves stuff like reading email
and parsing error messages to the non-core language.
Your way is a fairly huge undertaking to implement, and I'm not sure
what benefit it gives you beyond a "cleaned up" SDL that allows for
better modularity and better efficiency in parsing. In other words, why
wouldn't you make the "bytecode" a readable high-level language, and if
someone wants a specialized language, simply output the high-level
language, much the same way that people interface to RDBMs nowadays via
SQL source code?
(*) <http://sourceforge.net/projects/lome/> if you care.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 agree. POVRay should be a stand alone system. Write the script and POVRay
renders it.
My 2 cents is to look at actionscript in flash or JavaScript. Both are
object based with very strong tools. Ad the povray object classes and it
could do anything. The JavaScript engine in Firefox could be incorporated
given it is open source already.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Zeger Knaepen <zeg### [at] povplacecom> wrote:
>>> 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 ?
>
> Portability anyone?
>
> Not everyone uses Windows, you know.
What prevents POV-Ray to become :
[Render Core + Framework libraries + Official (new) SDL making use of
the framework]
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.
Unrealistic ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <no### [at] waycom> wrote:
> > 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.
> But the thing is that POV could maintain their OWN version of the
> language if they wanted.
How would that alleviate the problem I mentioned?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
m1j <mik### [at] hotmailcom> wrote:
> My 2 cents is to look at actionscript in flash or JavaScript.
I'm not sure that using a language which is completely different from
the current SDL is such a good idea.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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,
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
|
|
| |
| |
|
|
|
|
| |
|
|
