 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] rarius couk> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
